Hvis statslige parter indgår i projektet, vil disse med rette kunne kræve meget bred projektdeltagelse eller inddragelse af mange parter i projektet, for at ville/kunne deltage i projektet. Dette kan øge kompleksiteten i projektet betragteligt, specielt mht. kommunikations- og koordinationsaktiviteter.
Jo større og jo mere kritiske pilotafprøvningsprojekterne er, desto mere kompromissøgende og lav-ambitiøs skal man være i det man søger afprøvet.
For kritiske pilotafprøvningsprojekter skal der være et tilsvarende stærkt styregruppemedlem.
Hvis pilotafprøvningen "kommer ind fra siden" i forhold til et igangværende (udviklings)projekt, skal pilotprojektet søge et klart commitment til afprøvningen og til stadighed verificere dette commitment.
Tools og Open Source
Hvis projektet selv udvikler tools til brug i pilotafprøvning, skal man være opmærksom på, at der skabes flere leverandør-roller i projektet. Projektet bliver så at sige "leverandør til leverandørerne". For at dette skal lykkes skal der være meget fokus på kvalitet, support og kommunikation.
Kvalitet: Automatisk test, høj testdækning og synliggørelse af toolets kvalitet gennem diverse rapporter
Kommunikation: Svar hurtigt på forespørgsler og problemstillinger. Vi har haft gode erfaringer med at holde teknisk kommunikation blandt teknikere, f.eks. ved at indkalde til teknikermøder, når der har været en ny "stor" release af SOSI biblioteket. Det er vigtigt at melde ud, hvornår næste release leveres (inkl. hvilke fejl der rettes).
Support: Gode erfaringer med hurtig respons og villighed til at afhjælpe problemer. Hurtige bugfixes eller identifikation af "workarounds". Gode erfaringer med at afklare/identificere løsninger på problemstillinger med udviklere i pilotprojekterne.
Vær påpasselig med evt. "feature-creap" og "goldplating" i tools projekter. Fastlæg det nødvendige ambitionsniveau for at pilotprojekterne kan gennemfres forsvarligt ... men ikke højere! Yderligere ambitioner må indfris på kommende projekter.