Fleksibilitet og forudsigelighed

Alle ønsker et forudsigeligt projekt. Det er betryggende at vide hvornår man kan forvente de forskellige leverancer og hvad omkostningen bliver. Det gælder alle projektdeltagere, både blandt leverandøren og kunden.

Forskellige roller i projektet har ofte forskellige forventninger til projektets forudsigelighed. Kunden har tit en forventning om at leverandøren kan forudsige leveringsdatoer ret præcist. Det kan leverandøren også, hvis ikke det var fordi der er andre hensyn at tage end forudsigelighed.

Det er en afvejning af forskellige prioriteter hvor forudsigelighed i leverancerne kun er én blandt mange. En kendt leverancedato er en af de mest synlige egenskaber i et projekt, men det betyder ikke det er den vigtigste. Det er for det meste vigtigere hvad det så er som bliver leveret på de datoer.

Hvad er indholdet af et projekt

I softwarebranchen er det ikke så simpelt at definere indholdet af et projekt, med mindre man vælger at fokusere mere på evnen til at definere indholdet end at evaluere om det er det rigtige indhold.

Man kan vælge at fokusere på projektledelsens discipliner, definere klare krav, følge op på dem og se projektet i mål til den rigtige dato og med det korrekte indhold. Det er helt bestemt muligt. I det forløb er det bare meget nemt at glemme hvad formålet med projektet er. Formålet med et projekt er ikke at styre projektet perfekt. Formålet med projektet er defineret af projektet selv og skal skabe værdi for nogen.

I andre brancher er det måske simplere. “Du skal levere 5000 pakker letsaltet Lurpak i god stand til mit lager inden 1. september”.

Så simpelt er det desværre ikke helt i IT-branchen og uden at vide det, er det garanteret heller ikke så simpelt blandt distributører af smør.

Selvom et projekt indeholder klart definerede krav vil jeg påstå at der altid kan være tvivl om selv de mest simple og klarest definerede krav.

Ingen krav er perfekt defineret: Eksempel

Her er et eksempel fra det virkelige liv for små 10 år siden. Det er fra et projekt hvor jeg deltog som leverandør. Kravet lød sådan:

“Man skal kunne ændre sin adgangskode”

Jeg kan huske vi implenterede det med forbillede i hvordan man dengang skiftede adgangskode i Windows.

I det konkrete eksempel viste det sig imidlertid, efter implementeringen var færdig, at det var implicit for kunden, at man ikke skulle have lov til at skifte til den samme adgangskode som man havde allerede. Den regel er ret almindelig, men det er mindst lige så almindeligt at den regel ikke er til stede. Som leverandør var det ikke åbenlyst at den regel skulle implementeres.

Hvis man kun ser det fra leverandørens synsvinkel kan man sige at kravet var løst. Man skal kunne ændre sin adgangskode og det kan man.

Løsningen er åbenlys: Tilpas funktionen så den passer til det som kunden ønsker og forventer.

Ændringer tager tid og tid er penge

Ændringen fra dette eksempel er hurtigt klaret og næppe noget der vælter budgettet, men jeg bruger eksemplet her for at forklare at ingen krav er helt perfekt defineret og derfor er der brug for fleksibilitet når de bliver implementeret for at alles forventninger indfris.

Nogen tror løsningen er at lave kravene langt mere detaljerede. Desværre er der, som demonstreret med eksemplet herover, altid plads til misforståelser. Det er godt med gode beskrivelser, men det løser ikke behovet for fleksibilitet.

Fleksibilitet kræver tillid

Man bliver klogere undervejs i et projekt og derfor bør man være parat til at tilpasse projektet undervejs. Man skal være fleksibel. Men fleksibilitet kræver tillid.

Lad mig forklare hvorfor fleksibilitet kræver tillid, ved at tegne et billede af hvad der sker uden fleksibilitet og uden tillid.

I et projekt med en fast pris, vil leverandøren beregne prisen ud fra de nedskrevne krav. Hvis kravene implementeres af leverandøren, men kunden ønsker tilpasninger, så udgør dette et tab for leverandøren som de fra deres perspektiv er uden skyld i. Derfor vil leverandøren i dette tilfælde ofte ikke udvise særligt meget fleksibilitet.

De foregående tre sætninger er efter min mening årsagen til at offentlige udbud meget ofte går frygteligt galt.

Løsningen er en atmosfære af tillid i projektet. Sådan en abstrakt størrelse er svær at finde plads til en SKI-kontrakt, men den er afgørende for projektets succes.

Leverandøren skal have tillid til at kunden er rimelig sine ændringsønsker og kunden skal have tillid til at leverandøren er fleksibel og implementerer rimelige tilpasninger.

Hvis en leverandør tror de kan løse et projekt på en gode måde ved bare at implementere en række krav på den måde de selv har fortolket dem, tager de grueligt fejl.

Fleksibilitet står i modsætning til forudsigelighed

Hele forklaringen herover handler om hvorfor et godt projekt har behov for fleksibilitet.

Hvis et fleksibelt projekt medfører mulighed for ændringer undervejs – og hvis ændringer tager tid at implementere (hvilket de gør), så betyder det at et fleksibelt projekt gør projektets leverancedato uforudsigelig. De to ting er modsætninger til hinanden.

“Men hov, et SKI-projekt er notorisk ufleksibelt, burde offentlige udbud så ikke altid blive leveret til tiden?” tænker du måske. Svaret er nej, et ufleksibelt projekt giver konflikter som tager tid og samtidig ikke skaber værdi. Energien bliver brugt på andre ting end at godt projekt.

Fleksibilitet og en atmosfære af tillid er vejen frem til et godt projekt.

Leverandøren og Kunden

Nu har jeg refereret til “Leverandøren” og “Kunden” flere gange i dette indlæg, men det har faktisk gjort ondt hver gang. Når en gruppe mennesker bliver enige om at udføre et projekt sammen, får de det bedste resultat ved at arbejde sammen og glemme at de repræsenterer forskellige organisationer. Det skal se sig selv og hinanden som intet mere end projektdeltagere.

Et projekt hvor forudsigelighed er det eneste som er vigtigt, kan afsluttes meget nemt: “Vi leverer ingenting og det kan vi klare allerede i dag”.

Ethvert projekt har flere prioriteter end forudsigelighed. “Men man skal da levere det som er aftalt” , f.eks. kvaliteten af det man leverer. I denne branche, som i mange andre, er kvalitet en variabel størrelse uden et enkelt facit. leverer man sjældent fuldt standardiserede produkter, såsom 5000 pakker letsaltet Lurpak.

Opsummering

Et projekt skal skabe værdi. Det kræver fleksibilitet.

Fleksibilitet forårsager uforudsigelighed og kræver tillid.

Tillid kræver en sund atmosfære af samarbejde i projektet.