Estimering og planlægning, episode 1

Serien

Episode 1 – Den med forudsætningerne (du er her)
Episode 2 – Den med opsplitningen
Episode 3 – Den med den grove nedbrydning

Der er skrevet tykke bøger om, hvordan software bør planlægges og bygges. Og der er kurser. Og uddannelser med tilhørende certificeringer. Og konsulenter. Alligevel går det stort set altid galt (i en eller anden grad) af mange forskellige årsager. Jeg tror efterhånden, jeg har prøvet alle modellerne – fra ‘Plan, pssh – vi ved jo godt hvad vi skal lave’ over diverse agile modeller til Vandfald TTM (I nogle spektakulære tilfælde var det at lave projektplanen i sig selv et projekt, der krævede sin egen model…) og min erfaring er at den valgte model ikke har haft afgørende indflydelse på om projektet er lykkedes eller ej. Det her indlæg bliver en del af en længere serie, for jeg har holdninger (tm).

Risikofaktorerne

Størrelse – dræberen af alle projekt(plan)er. Der er masser af andre risici, men de blegner alle i forhold til størrelsen af projektet. Kompleksiteten og usikkerheden af et hvilket som helst projekt stiger ikke linært med størrelsen af projektet – de stiger eksponentielt. Forskellen mellem at skulle bygge software til at løse en specifik lille del af forretningen og så at skulle bygge software som skal håndtere 100 små sspecifikke dele af forretningen, som har indbyrdes afhængigheder… Bare at regne ud hvilke dele, der skal bygges før andre, kan hurtigt blive et projekt i projektet.

Det grundlæggende problem er egentlig ikke det at bygge software – som enhver udvikler vil fortælle dig, så er det ligeså nemt at følge en kravspecifikation som det er at gå på vandet – hvis de bare er frosset, skal det nok gå. Problemet er at software skal løse et forretningsproblem i virkeligheden – og virkeligheden er kompleks og ændrer sig over tid.

Så er der ledelsen af projektet og her mener jeg ikke projektlederen, men de personer, der har besluttet at projektet skal startes. Hvis der ikke er defineret et klart mål og en benhård prioritering fra start, kommer det til at være en klods om benet i hele projektets levetid.

Den sidste store risikofaktor er organiseringen af projektgruppen. Alle projekter har brug for involvering af nøglepersoner i processen – ligegyldigt om de er en fast del af projektgruppen eller der er afsat tid til at de kan agere konsulenter. Der er en række formål med det – dels at de får ejerskab, dels at der sikres mod misforståelser (læs: kvalitetssikring). Hvis et projekt ikke er solidt forankret, er der stor risiko for at slutproduktet aldrig opnår det potentiale, der var hele grunden til udførelsen.

Det er altid chefens skyld

Provokerende, men ikke desto mindre rigtigt. Chefers fornemste opgave er at sikre at deres medarbejdere lykkes med deres opgaver, herunder projekter – som en umiddelbar konsekvens: De skal skabe rammerne, som muliggør succes. Igen, vi taler ikke om projektledelsen – vi snakker om den ‘rigtige’ ledelse. Ligegyldig hvor god en udviklergruppe og projektledelse, du har – hvis ledelsen ikke er a) direkte involveret og b) bakker 100p op om projektet så er projektet virkelig udfordret. Jeg siger ikke, det er umuligt – jeg siger blot at det er ikke er lykkes endnu at opdrætte fisk i sand.

Konklusion

Selv hvis man gør alt det rigtige – små projekter, massiv ledelsesinvolvering og allokering af tilstrækkelige resourcer, er det ikke garanti for succes, men! der er en selvstændig pointe i, at selv hvis vi fejler – så er vi blevet klogere på forretningen og tabet af resourcer er ikke truende for forretningens eksistens. Jeg er abonnement på ideen om den lærende organisation og hvis vi gør det legitimt at fejle, så lærer vi hurtigere og er bedre rustet til næste projekt. For en ting er sikkert, den dag en forretning stopper med projekter er samtidig dagen, hvor der kun er afvikling tilbage.

Valg af projektmodel er en spændende nok diskussion, men hvis ovenstående ikke er på plads, er det som at flytte på skraldespandene i en brændende bygning – en god workout, men samtidig skønne, spildte kræfter.