For å oppnå et godt resultat kan det være fornuftig å se på prosjektplanen som en modell som kan utløse diskusjon og prioriteringer tidligst mulig. Dermed kan vi avdekke risikoer og utnytte mulighetene vi har innenfor prosjektrammen, og ut fra dette oppnå et så optimalt resultat som mulig.
Se planen som en modell
Det kan som sagt være en gunstig vinkling å se på gjennomføringsplanen som en modell. Hvor enkelt kan man gjøre det? En plan kan i en enkel form være å dele opp det som skal lages i planlagte små biter som skal lages i en prioritert rekkefølge. Å planlegge ved å dele det hele opp i biter er en framgangsmåte som f.eks. benyttes av prosjektrammeverket Prince2 (Se Styring av vellykkede prosjekter med Prince2, ISBN 9780113312382.). Det er også et grunnleggende prinsipp i smidig planlegging (Se Agile planning av Mike Cohn, ISBN 0471644463.) Hvis man skulle komme til å henge disse bitene opp på veggen slik at det blir tydelig hvor bitene hører hjemme i systemet og i hvilken rekkefølge man skal lage dem vil det bli klart for alle hva som er tenkt.
Det er spesielt én egenskap som må være tydelig for hver del, og det er hvor moden den er for å bli bygget. En slik status må stemme godt med rekkefølgen som er planlagt, og en visning av modenhet sammen med prioritering vil avsløre om det trengs ytterligere utredning og planlegging. Hvis en umoden bit er den som er planlagt bygget først må det gjøres noen endringer i gjennomføringen.
Det er for mange en uvant tanke at systemet ikke er ferdiganalysert ved oppstart av konstruksjon, og at man må detaljere biter underveis, men erfaringen viser at dette er en god måte å gjennomføre utvikling på, siden kompleksiteten er så stor. Dermed gir det mening å se på planen som en modell. Modeller har den egenskapen at de ikke oppfattes som fullstendige og endelige. En modell viser det som er det beste forslaget nå, men signaliserer også at det er mulig å endre den. Å tenke på denne måten gjør at man planlegger det man har grunnlag for å planlegge, og unngår å planlegge de delene der grunnlaget er ufullstendig. Der ser man i stedet at man må skaffe seg bedre grunnlag.
En modell er den mest effektive måten å dele informasjon på. Det å legge en utfordring på bordet (eller henge den på veggen) og se det samme når man flytter litt på deler og forsøker seg fram begrenser rommet for misforståelser drastisk.
Husk at det som implementeres etter hvert av software også kan endres underveis. Hvis vi bruker et hus som analogi kan vi utvide grunnmuren, bygge om røranlegget eller rive en bærevegg, og bygge opp huset igjen i løpet av natta. Bruk muligheten, men gjør det åpent, bevisst og med disiplin.
Det er et paradoks at mange antar at dette kan gjøres med mindre disiplin enn når man skal følge en ferdig plan. En ferdig plan er det bare å følge, det er enkelt. Vi må være bevisst disiplinen som trengs fra starten av for å diskutere og håndtere endringer. En endring må bli synlig, og alle må bidra til å oppdatere modellen.
Utløs diskusjon om prioriteringer
Så kommer det vanskelige: De som ser modellen skal kunne gå fram til den, med rak rygg og rolig puls, peke på en av delene og kunne si: «Den delen der kan vi da ikke vente så lenge med, risikoen er alt for stor!» Hvis det ikke er spesielle motargumenter kan man endre planen og gjøre det mulig å vise hvordan den ser ut etter endringen. Alle kan så studere og eventuelt forbedre planen igjen.
Det kan kreve stor mental omstilling å stille spørsmål ved en prioritering lagt fram av ledelsen uten at dette er et problem. Det vil være viktig for en leder å være klar og ryddig nok i sin behandling av planen, men også invitere til dialog rundt uenigheter og dissidens, som jeg skrev i blogginnlegget Moderne ledelse i en smidig verden.
Det finnes en annen fordel ved å bruke en prioritert liste, skjønt noen med lederansvar kanskje vil se det som en ulempe. En person kan bare gjøre en ting om gangen. Et team må også ha en klar prioritering for sine oppgaver. Hvis man endrer på modellen ved å prioritere noe opp betyr det at man prioriterer noe annet ned. Disse to tingene henger ikke så tydelig sammen for alle, og da er det greit å ha et verktøy som gjør det åpenbart.
En kan forestille seg at det er mulig for en gruppe å bli enige gjennom diskusjon. I praksis vil det være klokt å ha en person som tar med seg alle argumentene og har som oppgave å bestemme rekkefølgen i den nærmeste perioden. Det vil være uheldig å endre planer for konstruksjonsarbeid som allerede er startet.
Ved å vedlikeholde en liste som stadig kan endres har vi lagt det metodiske og verktøymessige grunnlaget for å ha en mulig diskusjon om planen. En slik diskusjon ville ført til stor usikkerhet uten en bevisst og disiplinert bruk av en prioritert liste eller modell, som nevnt over.
Utnytt mulighetene innenfor prosjektrammen
Når vi har blitt dyktige på samspillet kan vi utnytte mulighetene som ligger innenfor de rammene som finnes i et prosjekt ved å stadig kunne vurdere beste framgangsmåte hvis betingelsene for gjennomføringen endrer seg av teknologiske eller andre årsaker.
Tenkningen beskrevet her underbygger Lean-prinsippet om å ta beslutningen i siste ansvarlige øyeblikk. På engelsk: Decide as late as possible. Dette er beskrevet av Tom og Mary Poppendieck i deres bøker om teamet, f.eks. i Lean Software Development, An Agile Toolkit, ISBN 0321150783. Det siste ansvarlige øyeblikk er passert når beslutningen ikke ble tatt bevisst, men et av alternativene ikke var mulig å benytte seg av lenger fordi beslutningen tok for lang tid.
Ved at alle parter er med på å dele opp løsningen i biter skapes muligheter for deg selv og teamet. Å skape muligheter for alternative måter å gjennomføre arbeidet på er den optimale forberedelsen for å lykkes underveis. Det gir mulighet til å holde framdrift under endrede betingelser.
Det er flere og flere som bruker en metode som gir mulighet for å endre planen underveis. F.eks. NAV IKT har komplekse systemer de må videreutvikle og vedlikeholde. De har gjennom avtaleverk, med dynamisk avtaler, og gjennom bevisst bruk av verktøy for håndtering av produktkø åpnet opp for muligheter til endring i gjennomføringen fram mot sine fire årlige hovedleveranser til produksjonsetting. Dette arbeidet fungerer utrettelig år etter år, men informasjon om dette kommer ikke så godt fram til det brede publikum. Min erfaring er at det er mange som kan lære av NAV IKTs vei mot en smidigere gjennomføring.
Øk mulighetene for å lykkes
Vi mennesker blir ofte forført av en detaljert og fullstendig plan og av mennesker som er dyktige til å tegne et fullstendig og ufeilbarlig bilde. Denne effekten blir beskrevet av nobelprisvinner Daniel Kahneman i hans bok Tenke fort og langsomt. For komplekse oppgaver finnes det svært få genier her i verden som kan lage den fullstendige løsningen ved kun forhåndsanalyse, og enda færre som kan spå om hvilke betingelser som endrer seg underveis. Det kan være klokt å være sikker på at det finnes muligheter å diskutere.
Under en diskusjon av metode for gjennomføring for noen år siden spurte konsulentsjefen jeg jobbet sammen med om hvorfor jeg er så opptatt av spesifikasjonen av løsningen. Jeg måtte strengt tatt tenke meg litt om på det tidspunktet før jeg fant svaret på dette. Så gikk det opp for meg at hvis du har brukt mye tid på å dele opp det som skal lages i gode biter som du har snudd og vendt litt på har du også tenkt mye på hvordan bitene kan lages, og dermed har du gitt deg selv muligheten til å finne alternative måter å sortere bitene på.
Mange IT-prosjekter går over kostandsrammen og tiden. En del av grunnen er at utvikling av IT-løsninger er komplekst arbeid. Da må vi forberede oss godt ved å dele opp elefanten, holde mulighetene åpne og hele tiden sørge for å gjøre det synlig hva som er den beste veien framover.
Har du lyst til å jobbe som prosjektleder i et selskap som har ansvaret for noen av de største digitaliseringsprosjektene i offentlig sektor, sjekk ut våre ledige stillinger her.
Les mer om prosjektledelse i Visma her.
