Estimering og planlægning episode 2

Serien

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

Lad os nu sige, at alle de perfekte forhold er tilstede for projektet – ledelsen er med, resourcerne er tilstede og der er et solidt forankret mål for det hele (Alt det i episode 1). Nu er det tid at få projektet splittet op. Igen, projektmodellen er ikke rigtig vigtig på det her stadie – det er mere et spørgsmål om at danne rammerne.

Detaljer er fjenden

På nuværende tidspunkt er vi interesseret i hvad der skal bygges, ikke hvordan. Hvilket web framework, der skal anvendes; om det skal være en microservice arkitektur; hvor det skal hostes. Alt sammen i bedste fald distraktion på nuværende tidspunkt. Nej, vi skal have klarlagt præcis hvilke forretningsbehov projektet skal løse – og, mindst ligeså vigtigt, hvilke procedurer vil vi gerne ændre. Der skal være noget ‘godt’ for enden af regnbuen, der skal være noget mærkbart, der er ‘bedre’ i forretningen bagefter. Hvis det er et kundevendt projekt, skal der være ’noget for dem’. Det virker banalt at skrive det, men det går overraskende ofte galt. Enten glemmer man de ændringer, der skulle til i organisationen for at understøtte det nye software – eller man glemmer at spørge brugerne, hvad de egentlig har brug for.

Prioritering, prioritering, prioritering

Efterhånden som projektet bliver nedbrudt i hvilke arbejdsgange, processer og organisationsændringer, der er påvirket – så skal det prioriteres, hårdt. Der kan kun være en prioritet 1. “Jamen, det hele er vigtigt!” (jeg kan høre præcis den indkøbschef for mit indre øre) Og ja, det hele er vigtigt, ellers ville det ikke være med i projektet – vi beskæftiger os ikke med ikke-vigtige ting. Men. Det er ikke lige vigtigt. Tænk det som “Hvis det her ikke er der, er projektet dødfødt”-vigtighedsgrader. Altså, design projektet efter, at hvis vi når de 80% højst prioriterede ændringer, så er det en success (læs: det giver værdi for forretningen). 80-150% er bonus. (Og ja, jeg har været med i projekter, hvor vi nåede alle prioriteterne og fik et par boblere med)

Rækkefølgen – Byg det vigtigste først

Med mindre. Der vil altid være afhængigheder mellem de prioriterede opgaver – og så er der den eviggyldige sandhed: Det psykologiske betyder 71,9% [1] af succes-raten for projekter. Et feedback-loop så tidligt som muligt bør prioriteres. Det har mindst to formål: Tidlig identificering af logiske fejlslutninger og følelsen af fremskridt. Igen, stadig uafhængigt af om vi kører med vandfald eller agilt. Men ellers er hovedreglen – det vigtigste først – og byg hver del færdig [2]. Og ja, det inkluderer ting som tilgængelighed og lokalisering. Det er a) svært og b) tidskrævende at bygge ind som en eftertanke. I agile kredse kalder man det DoD (Definition of Done) – hvornår kan man betragte dette område for færdigt. Testere kalder det Acceptance Tests. Der skal være 100p enighed om det fra alle, der har bacon på linjen.

Konklusion

Den her fase af projektet er super-kritisk. Den skal få alle, der er med i projektet på samme side i manuskriptet i forhold til Hvorfor. Hvor passer det her ind i forretningen; hvem hjælper vi; hvad ændrer vi – find selv på flere hv-ord. Alt for ofte har jeg set diskussioner, der er kørt ud af tangenter om hvorvidt det ene framework var bedre end et andet.

[1] Bestemt ud fra upartisk terningerul af min datter.
[2] Ikke færdig-færdig – funktion over form (læs: Vent med polering)