Når vi planlægger et it-projekt eller et hvilket som helst projekt for den sags skyld, planlægger vi ikke at levere for sent.
Vi forventer at kunne aflevere projekter til tiden.
Hvorfor er det så altid, at vi jubler, når it-projekter afleveres til tiden?
Det burde være naturligt. Deadlines er til for at blive overholdt – også de umulige af dem. Det har vi
lovet forretningen.
Jubelrus
Men vi er blevet så vant til, at projekter skydes, at vi finder os selv i en jubelrus af cola og pizza, når et projekt for en gangs skyld leveres til tiden.
Og det til trods for, at it-projekter, der leveres til tiden sjældent holder sig på hverken budget eller kvalitet.
Hvad er så vigtigst i situationen?
At aflevere til tiden og juble eller at aflevere den rigtige løsning senere end planlagt og derefter juble – eller sagt på en anden måde, mirakler tager længere tid – hvad vælger du?
Mirakler skal der til
Og mirakler skal der til, hvis umulige deadlines skal nås.
It-projekter har altid haft problemer med at levere til den planlagte tid.
Alt for ringe planlægning og mangel på erfaring får tit skylden.
Erfaringer gør det muligt for en at genkende fejl, når man begår dem igen, og det er lige netop det, it-projekter oplever gang på gang.
Der kommer nye ansigter til, nye chefer og nye ideer, men det er de samme fejltagelser.
Deadlines defineres for stramt og kvaliteten, budgettet eller tiden må ofres på it-alteret.
Budgettet kan diskuteres.
Udgifterne kan fordeles på andre budgetter, og merudgifterne kan indhentes de efterfølgende år på besparelser ved implementeringen af det nye system.
Kvalitet kan altid diskuteres.
Tiden kan ikke diskuteres
Med introduktionen af iterativ udvikling er det muligt at argumentere for ikke at levere hele pakken, og at lægge den resterende funktionalitet ned til driften eller ind i en senere leverance.
Tiden – derimod – kan ikke diskuteres.
Den kender vi alle, og den kan vi alle gennemskue.
Tiden bliver dermed hurtigt et symbol på projektets succes og fremdrift, og den vigtigste parameter for projektet.
Det bliver psykologisk vigtigt for projektet, projektledere, projektdeltagere og andre interessenter at levere et eller andet til den aftalte tid.
Vi som mennesker har en ukuelig tro på os selv i planlægningen.
Vi sjusser os frem
Vi estimerer os frem til en endegyldig deadline via en jungle af matematiske formler og tidligere erfaring eller mangel på samme, uden hensyntagen til hvad udviklerne, teknologien og eksperterne siger.
Og uden hensyntagen til at verden ændrer sig; at det, der var rigtigt i begyndelsen af projektet, ikke er rigtigt seks måneder henne i projektforløbet.
Er projektet estimeret forkert af en eller anden grund og på vej ned i afgrunden, skal ledelsen bekende kulør straks.
Ledelsen skal lytte til projektdeltagerne på gulvet, projektledere, forretningen og eksperterne, og ledelsen skal høre godt efter.
Hvis en given statusrapport fra projektet er rød, skal den ikke af ledelsen fremstilles som gul over for andre interessenter, eksempelvis kunden eller forretningen.
Det kræver derfor også, at alle i hele projektet tør sige tingene, som de er.
Ellers får ledelsen blot et glansbillede – aldrig det korrekte billede.
Får projektet først lov til at løbe løbsk uden tidlig erkendelse af problemer, ender det med at alle tre parametre skal justeres.
Vis ansvar
Jo før ledelsen viser sit ansvar, jo før kan man komme forretningen eller kunden i møde med en grundig analyse, overvejelser og forslag om, hvad der skal justeres på, i hvor høj grad og hvordan.
På side 1 i en hver projektledelseshåndbog står der, at man skal fejre alle succeser – store som små.
Så det er klart, vi jubler, når it-projekter leveres til tiden.
Det er den første succes, projektet får – måske i lang tid.
Kristian Fischer er managementkonsulent i PA Consulting Group.
Computerworlds klummer er ikke nødvendigvis udtryk for Computerworlds holdninger, men er alene udtryk for skribentens holdninger.
