Denne artikel stammer fra det trykte Computerworlds arkiv. Artiklen blev publiceret den Computerworld d. 18. juni 2004.
Har it-folket lært at styre uden om faldgruberne på vejen fra idé til færdigt it-system? Næppe. Se bare på Systematic og Århus Amt med EPJ-projektet, og IBM og Krak med deres virk.dk.
LANDMINER
It-folk behersker tilsyneladende stadig den simple kunst at forkludre et it-projekt, mener cand. polit. Christian Barnholdt. Han har været systemkonsulent i IBM, it-leder i Nordjyllands Amt og forskningschef i IDC Nordic, men har de seneste 16 år ernæret sig som it-forfatter og it-skribent.
Da 80'erne og 90'ernes store it-skandaler, som for eksempel Danmarks Radios DORA-projekt, rullede over landet, satte Barnholdt sig for at analysere årsagerne. Han blev mødt med en mur af tavshed. Ingen havde lyst til at lade sig udstille. Den holdning har ikke just været befordrende for at dele erfaringer og undgå skandaleprojekter i fremtiden.
- Når selv IBM og Systematic, som jeg opfatter som utroligt professionelle, får problemer, så tyder det på, at årsagerne til projektkriserne er svære at udrydde, siger Christian Barnholdt.
Som it-skribent hjælper Christian Barnholdt i dag danske it-leverandører med at skrive kundecases, og han støder på mange professionelt styrede it-projekter, der bliver færdige til aftalt tid, pris, kvalitet og funktionalitet, understreger han, så mange it-folk i dagens Danmark har lært at undgå faldgruberne.
Don't try this at home
På trods af kildernes uvilje til at tale om fiaskoerne dengang, tog han fat på en række af de kuldsejlede projekter.
Her præsenterer Computerworld Barnholdts liste over ting at gøre, hvis man rigtigt skal ødelægge et it-projekt:
• Lav en hastig og kortsigtet analyse af behovene.
• Lav en uklar og tynd krav-specifikation.
• Sørg for, at disse to faser gennemføres lynhurtigt, helst under tidspres.
• Hold de fremtidige brugere helt uden for projektet - og især fra arbejdet med punkt 1 og 2.
• Sørg for, at der er uklarhed, og, endnu bedre, uenighed, om projektets mål, metoder og forløb. Det allerbedste er uenighed mellem leverandør og køber.
• Lav en tyk og uforståelig systembeskrivelse.
• Skab en uklar rolle- og ansvarsfordeling.
• Vælg helt uprøvet teknik.
• Hold ledelsen borte fra projektet. Ledelsen behøver heller ikke aktivt at støtte arbejdet, så længe den blot bevilger pengene.
• Hvis der er modstridende interesser mellem systemfolk og brugere, så giv systemfolkene ret - hver gang.
• Uddeleger ansvar, uden at uddelegere magt og indflydelse.
• Hold det skjult for alle medarbejdere, hvad projektets formål og konsekvenser er - især hvad angår dem selv.
• Giv de projektansvarlige mange forskellige opgaver med projektet, og lad dem fortsat passe deres normale arbejde ved siden af.
• Sørg for, at der ikke opstår sammenhold og korpsånd.
• Overlad alt ansvaret til projektledelsen. De menige medarbejdere skal blot gøre, hvad de får besked på.
• Sæt en uerfaren projektleder på de mest kritiske og komplicerede projekter - og skift ham ud regelmæssigt.
• Vælg en leverandør uden branchekundskab, uden dokumenterede referenceinstallationer, og uden evne eller lyst til at indleve sig i brugernes verden.
• Tag venligt imod alle ændringsforslag og ekstrakrav, og fasthold den oprindelige tids- og økonomiplan. Lav heller ingen ændringer i kontrakten i den anledning.
• Begynd udviklingsarbejdet så hurtigt som muligt, helst før kravspecifikationen er lavet.
• Vær altid superoptimist med tids- og ressourceplaner.
• Hold dine problemer for dig selv - og giv altid et lyserødt billede til modparten.
- Dette er de mest typiske faldgruber. Utallige it-folk er skvattet i dem, og flere vil gøre det i fremtiden. Men der er trods alt kun spidse pæle i bunden af nogle få af dem. Man ved desværre bare aldrig i hvilke, siger Christian Barnholdt.
Billedtekst:
- Kun de færreste it-fiaskoer er nogensinde blevet grundigt analyseret, i hvert fald af andre end de direkte involverede. Men der er alligevel nok af kendte cases til, at man kan udpege de værste og de hyppigste af de næsten utallige fejl, som man kan begå i et større it-projekt, siger Christian Barnholdt, cand.polit., it-skribent og tidligere systemkonsulent hos IBM.
Fakta:
Mordet på et it-projekt
Eksempel på aftale mellem leverandør og kunde:
"På grund af tidsnød er parterne enige om, at der ikke udarbejdes en egentlig kravspecifikation. Men det nye system skal kunne alt, hvad det gamle kan, plus en række forbedringer, som aftales undervejs. Svartiderne skal være uændrede. Parterne vil sammen udarbejde en kravspecifikation så hurtigt som muligt, men projektet må ikke blive forsinket af denne årsag."
