Computerworld News Service: Det er ikke ligefrem ukendt i it-branchen, at projekter ender i fiasko.
Og mange af de, der har haft den tvivlsomme fornøjelse at deltage i et mislykket it-projekt, havde sandsynligvis længe før lanceringsdatoen en mistanke om, hvor det bar hen ad.
En sådan fornemmelse er uvurderlig i et konkurrencepræget felt som it - men kun hvis man handler på den omgående og professionelt.
Hvad enten det er for at gå i en bue udenom projekter, der er dødsdømt på forhånd, eller for at styre fejlslagne projekter tilbage på rette kurs, så er man nødt til at kunne genkende advarselstegnene, lang tid før et projekt begynder at gå op i limningen.
Derfor har vi her samlet 11 advarselstegn, du bør holde øje med i forbindelse med en vurdering af it-projekters sundhed.
Vær proaktiv, når du støder på et af dem - eller forlad den synkende skude, hvis det er muligt.
Det kan redde din karriere.
Disse ting skal være på plads med støtte
Advarselstegn nr. 1: Projektet er søsat uden opbakning fra ledelsen
Det er en sikker opskrift på fiasko, hvis et projekt kommer for godt i gang uden støtte fra den øverste ledelse.
Det er en situation, der som regel udspiller sig, som følgende: En stærk personlighed i firmaet har en fantastisk god idé og begynder at planlægge møder og allokere ressourcer uden at vente på godkendelse fra den øverste ledelse.
Mange af sådanne projekter når dertil, hvor der er brug for at investere et større beløb, hvorefter de stopper brat.
Ofte er det kun projektets ophavsmand, der er klar over, at projektet hverken er godkendt eller har fået tildelt et budget.
For at undgå at blive draget ind i sådanne projekter bør du altid spørge om hvem i ledelsen, der er sponsor for projektet, og hvor stort et budget, der er sat af.
Uacceptable svar
Det er ikke et acceptabelt svar, at budgettet endnu ikke er fastsat, fordi man ikke ved, hvad det kommer til at koste, før projektet er godt i gang.
Hvis du er konsulent og bliver involveret i et sådant projekt, bør du sikre dig, at der faktisk er allokeret ressourcer, før du deltager i mere end det indledende møde.
Du behøver ikke kende det endelige budget, men du skal være sikker på, at ledelsen faktisk støtter op om projektet og har en idé om, hvad det kommer til at koste.
Jeg har deltaget i store projekter, der åbenlyst ville komme til at koste millioner af kroner, men hvor ledelsen troede, det drejede sig om højst et femcifret beløb.
Den slags projekter skal man ikke involvere sig i.
Disse ting skal være på plads med planer
Advarselstegn nr. 2: Der findes ingen detaljeret projektplan
Software til projektplanlægning kan være kompleks og frustrerende at bruge.
Det eneste, jeg hader mere end at lægge en detaljeret projektplan, er at være involveret i et projekt, der ikke har nogen.
Formelle projektplaner tvinger projektlederen og alle deltagere til at overveje alle de nødvendige faser og trin samt deres rækkefølge.
Hvis man ikke har nogen plan, kan det kun gå galt.
Solid og detaljeret projektplan
Ethvert projekt, der estimeres til at tage mere end to uger, bør have en solid og detaljeret projektplan.
Hvis du præsenteres for et projekt, der ikke har det, så læg selv en plan.
Det vil tvinge alle andre til at forholde sig til alle opgaverne og finde på realistiske tidsplaner. En detaljeret projektplan er langt bedre end nogens "bedste bud" eller mavefornemmelse.
Disse ting skal være på plads med med tidsforbrug
Advarselstegn nr. 3: Der planlægges møder uden skelen til deltagernes tid
Når projektlederen eller teamlederen skemalægger møder oveni deltagernes andre vigtige, forudgående aftaler, så ved du, at projektet er dødsdømt.
Det betyder nemlig, at vigtige deltagere vil være fraværende, og at mødernes formål og effektivitet dermed undermineres.
Løsningen er dog ligetil: Brug lidt tid forud for skemalægningen af møder på at lære de vigtigste deltageres aktuelle faste aftaler at kende.
Beslut dig
Endnu vigtigere så find frem til en håndfuld tidsrum, hvor de fleste kan, og vælg et af disse tidsrum.
Gå ikke for langt med hensyn til at lade deltagerne stemme om forskellige tidsrum - det kan medføre modstand hos de, der ikke får opfyldt deres ønsker.
Lev i stedet op til din rolle som leder og beslut dig for et tidsrum, som du ved, alle kan leve med.
Hvis det bliver nødvendigt, kan du altid justere det senere.
Sørg desuden for at offentliggøre tidsrummet for projektets faste møder, så andre i organisationen ikke planlægger møder samtidig.
Det er også en god idé at lægge møder før frokost.
Folk er generelt mere produktive og vil med større sandsynlighed deltage i mødet tidligt på dagen.
Møder efter frokost skal som regel kæmpe med den sløvhed, der kommer af, at deltagerne netop har spist sig mætte, og konkurrere med de prioriteter og dramaer, der er opstået tidligere på dagen.
Møder lige efter frokost og lige før fyraften er som regel de mindst produktive, og hvor færrest i det hele taget møder op.
Disse ting skal være på plads med brugerne
Advarselstegn nr. 4: Brugerne involveres for lidt eller for sent
Alle, der tager selv et grundlæggende it-kursus på universitetsniveau, lærer, at man skal involvere brugerne tidligt i ethvert udviklingsprojekt.
Derfor er det overraskende, at der stadig gennemføres store og komplekse projekter, der næsten er afsluttede, før brugerne bringes på banen.
Jeg har set mange store projekter, der fuldstændigt køres af sporet, fordi man alt for sent lærer af brugerne, at en eller flere processer slet ikke fungerer i praksis.
Sørg for at tage faktiske brugere med på råd helt fra projektets start.
Det kan ikke ske for tidligt.
Meget inddragelse er godt
Jo mere brugerne er involveret, des større er chancerne for, at projektet lykkes.
Hvis det handler om udvikling af en løsning til flere afdelinger, så sørg for, at der er en bruger med fra hver afdeling.
Sørg også for, at de deltagende brugere forstår projektets mål, og at de føler, at de frit kan give deres ærlige mening tilkende.
Tidlig brugerinddragelse resulterer typisk i hurtigere og bedre accept blandt slutbrugerne, hvis der opstår problemer eller det viser sig at være nødvendigt at foretage upopulære ændringer.
Disse ting skal være på plads med specifikationer
Advarselstegn nr. 5: Der udvikles til minimumspecifikationer
Der er ikke noget, der dræber et projekt, som når man køber hardware, der kun med nød og næppe opfylder minimumskravene.
Leverandører er generelt berygtede for at forsøge at holde projektomkostningerne nede ved at underspille hardwarekravene til deres løsninger.
Ofte angives der både minimumsspecifikationer og anbefalede hardwarespecifikationer.
Kloge projektledere køber hardware, der overgår selv de anbefalede systemkrav.
Hvis der opstår problemer, så kan hverken leverandøren eller kunden skyde skylden på dine hardwarebeslutninger.
Sørg også for, at al hardware og software er blevet testet til at være indbyrdes kompatibel.
Detaljer er afgørende
Detaljerne kan være overordentligt vigtige i forbindelse med indkøb af teknologi.
Hvis en leverandør for eksempel hævder at have gode erfaringer med at køre MySQL på Linux, så pas meget på med at kræve, at MySQL skal køre på Windows.
Måske siger leverandøren, at det godt kan lade sig gøre, men har ikke megen erfaring med det.
Hvis du afviger fra leverandørens anbefalinger, så sørg for at få leverandørens accept på skrift.
Det skader heller ikke at indhente tidligere kunders erfaringer med lignende konfigurationer for at finde ud af, hvad der gik godt og hvad der gik skidt, hvis de afveg fra de anbefalede specifikationer.
Disse ting skal være på plads med test
Advarselstegn nr. 6: Der testes for sent
Test er helt essentielt for et projekts succes.
Hvad enten det drejer sig om enhedstest (som tester et enkelt aspekt af systemet) eller integreret test (som tester alle komponenter heriblandt tilkoblede eksisterende systemer), så bør test foretages af aktuelt ansatte med et test-script.
Dette test-script bør indeholde alle input, trin for trin, som testerne skal foretage.
Der bør også laves en detaljeret beskrivelse af, hvordan alle output bør se ud.
Alle scenarier
Alle scenarier bør testes - heriblandt både med gode og dårlige data.
Nogle gange er resultaterne fra kendte dårlige data mere interessante end test, der falder ud som ønsket. Man bør også foretage load-test for at se, hvordan systemet og netværket opfører sig under stor belastning. Testerne skal kende til de forventede resultater og rapportere enhver afvigelse.
Disse ting skal være på plads med b-planer
Advarselstegn nr. 7: Der er ingen planer for hvis det går galt
Selvom vi gør vores bedste, går tingene ikke altid efter planen.
Enhver projektleder er nødt til at vide, hvordan en succesfuld lancering ser ud - og hvornår det er på tide at erkende fiaskoen.
Ethvert projekt skal have en plan B for lanceringen i det tilfælde, at projektet kører af sporet eller der sker nedbrud.
Alt for mange lanceringsbegivenheder er drevet af den forestilling, at det ikke kan gå galt.
Her kan problemet være, at projektlederne ikke sørger for, at der laves backup, at de ikke på forhånd har defineret succes og fiasko, eller at de ikke har forberedt teamet på, hvad der skal ske i tilfælde af nedbrud ved lanceringen.
Det er kritisk, hvis man først finder ud af, når et projekt snubler, at der ikke er nogen vej tilbage. Det er et resultat af dårlig planlægning.
Hvad skal der ske ved nedbrud?
Med få undtagelser bør man have planer for, hvad der skal ske ved nedbrud, og gøre det muligt at gå tilbage til det gamle system, hvis problemet er stort nok.
Der er ingen, der har lyst til at lægge planer for, hvad der skal ske ved nedbrud, fordi det er ubehageligt, når tingene ikke går efter hensigten.
Men det er som regel endnu værre og kan sætte en stopper for karrieren, hvis man ikke er i stand til at genoprette systemet ved et alvorligt nedbrud.
Det er en god måde at score point, hvis det står klart for den øverste ledelse, at man havde en plan B klar, som blev fulgt til punkt og prikke, da det mod forventning gik galt.
Det bliver en helt anden samtale, hvis man, mens nedetiden trækker ud, er nødt til at forklare ledelsen, at der ikke er nogen vej tilbage og vejen frem er lang og tornet.
Disse ting skal være på plads med eksperterne
Advarselstegn nr. 8: Ekspertanbefalinger afvises uden test
Der findes mennesker, der indhenter råd fra eksperter, men alligevel - hver eneste gang - vælger ikke at følge anbefalingerne.
Og så beklager de sig, når tingene ikke fungerer.
Sørg for ikke at gøre sådan. Og sørg for, at sådanne personer ikke har noget større beslutningsansvar i dit team.
Det kan godt være i orden at spørge eksperter til råds men ende med at gøre noget tingene anderledes.
Der findes masser af komplekse problemstillinger, der ikke har nogen løsning, der er den eneste rigtige, og det kan være tegn på godt lederskab at turde skære igennem.
Men hvis du går imod anbefalingerne og resultatet ikke fungerer, så skyd ikke skylden på konsulenten.
Husk at teste
Hvis man vil afvige fra leverandørens eller konsulentens anbefalinger, så er man nødt til at teste resultatet af ens ændringer før lanceringen.
Også selvom leverandøren eller konsulenten godkender afvigelsen fra anbefalingerne, skal du sørge for at teste ændringerne.
Mange projekter fejler, fordi projektlederne foretog nogle mindre ændringer, som leverandøren eller konsulenten rystede på hovedet af i baggrunden.
Det er overraskende, hvor mange eksperter, der opgiver at protestere, når de står overfor en meget stærk kunde, der tilsyneladende ved bedre end de erfarne konsulenter.
Alle vil gerne være venner og alle håber, at det alligevel går.
Men hvorfor nøjes med at håbe, når man kan teste? Men lyt som udgangspunkt til dine eksperter.
Disse ting skal være på plads med lanceringsplanerne
Advarselstegn nr. 9: Lancering sker op til en weekend eller ferie
Mange projektledere planlægger lancering af det nye system i weekenden eller ferien, så eventuel nedetid ikke forstyrrer ansatte og kunder.
Det giver jo på sin vis mening, men på disse tidspunkter er det som regel også sværere at få fat i it-supporten.
Det kan godt være, at den primære leverandør er til stede, men support fra tredjeparter er måske ikke tilgængelig, hvilket også kan gælde mange af teammedlemmerne.
Det er aldrig optimalt at tale med sin bedste database-fejlfinder over telefonen, mens han er på ferie med familien.
Disse ting skal være på plads med forventningerne
Advarselstegn nr. 10: Forventningerne er uafklarede
Når et nyt system skal erstatte et gammelt system, er det nyttigt, hvis alle forstår, hvad der kan forventes af det nye system. Hvordan kommer det til at fungere?
Hvad er der af forskelle med hensyn til transaktioner og hvor lang tid, de tager?
Hvem ringer slutbrugerne til, hvis de har problemer?
Hvor lang tid vil det særlige supportteam være til stede efter lanceringen?
Et nyt system vil altid frustrere brugerne i starten, men hvis du opstiller realistiske forventninger og giver folk gode muligheder for at få hjælp, har problemerne det med at forsvinde hurtigere, så du også hurtigere vil ende med mere tilfredse kunder.
Disse ting skal være på plads med oplæring
Advarselstegn nr. 11: Oplæringen er mangelfuld
Alt for mange projektledere vælger at skære ned på oplæringen, hvis budgettet er i fare for at blive overskredet.
Ofte er der her en lidt for skråsikker leder, der hævder, at systemet er så brugervenligt, at der faktisk slet ikke er brug for oplæring.
Hvis du hører noget i stil med:
"Vi oplærer da bare hver anden bruger, og så kan de oplære hinanden," eller:
"Vores brugere er ret gode til at regne tingene ud, så de skal nok selv lære systemet at kende på et par dage," så ved du, der er problemer forude.
Det er ikke kun brugerne, der har brug for oplæring, men også projektlederne, fejlfinderne og helpdesken.
Vær forberedt på, at det nye system giver forsinkelser, hvis der ikke gives tilstrækkelig oplæring.
Oversat af Thomas Bøndergaard
