Ikke gjør noe uten et klart formål

Du bør ikke gjøre noe med mindre det har et klart formål. Tenk deg to parallelle verdener hvor alt er det samme bortsett fra det du vurderer å gjøre: Hvor annerledes ville disse verdenene være? Er forskjellen verdt innsatsen for å gjøre det?

Hvis du ikke har en klar hensikt i tankene og bare gjør noe fordi alle andre gjør det, eller alle sier at det er viktig å gjøre det, da

• Kan det ikke ha en reell fordel i ditt tilfelle, og derfor kan du ikke få noe ut av det. eller
• Det kan fortsatt ha potensielle fordeler i ditt tilfelle, men fordi du ikke har formålet i fokus, kan det ikke hjelpe deg med å realisere fordelene.

Eksempel: Porteføljer og programmer

Hvis du er involvert i utvelgelse og oppstart av prosjekter, bør du sørge for at du fokuserer på fordelene og problemene som må løses, i stedet for produktet som skal realisere disse tingene. Det klassiske eksempelet er produsenten av heiser som pleide å motta klager om hastigheten på sine heiser, og så hadde de kjørt flere prosjekter for å øke hastigheten uten full suksess. Det fortsatte inntil de bestemte seg for å fokusere på problemet (folks kjedsomhet eller ubehag) i stedet for den “naturlige” løsningen (raskere heiser). Resultatet var at de satt opp speil i heisene, og det løste problemet enkelt og billig.

Husk at prosjektledelsen handler om å gjøre ting riktig, mens porteføljestyring handler om å gjøre de riktige tingene. Det spiller ingen rolle hvor godt du kjører prosjektene dine; det vil ikke fungere bra hvis du gjør feil prosjekter. Det handler om å ha et formål.

Eksempel: Prosjektet som helhet

Fleksibiliteten i selve produktet varierer mellom prosjekter. I enkelte IT-utviklingsprosjekter er produktet helt fleksibelt, og den endelige formen avhenger av tilbakemeldingen som vil bli generert av inkrementene i produktet underveis i prosjektet, noe som krever en adaptiv (Agile) tilnærming. Dette er praktisk sett en kombinasjon av portefølje-, program- og prosjekt, og krever maksimal oppmerksomhet til det endelige målet. Det er en god idé å dokumentere hensikten og ha den lett tilgjengelig. Det er et av formålene med “produktvisjon”, som brukt i noen Scrum-prosjekter. Oppmerksomheten på forretningsverdi i Agile-prosjektene er deres måte å sikre tilpasning med formål.

I andre typer prosjekter hvor produktet er relativt fast og det finnes andre mekanismer for å sikre at det identifiserte produktet vil tilfredsstille formålet, er det mulig for prosjektgruppemedlemmene å skifte en stor del av fokuset fra formålet til selve produktet (dermed prinsippet om fokus på produkter “PRINCE2^®), men oppmerksomhet mot formålet er fortsatt nødvendig for å sikre at det som blir bygget vil tilfredsstille formålet, som kan gjøres ved å sammenligne de prognostiserte fordelene med de forventede fordelene ( dermed prinsippet om “continued business justification” og “business case” temaet i PRINCE2^®).

Når et prosjekt kjøres for en ekstern klient, vil klienten ha sin egen hensikt for prosjektet, og bedriften din vil ha en annen hensikt. Du bør forstå og bruke begge disse for å virkelig lykkes.

Eksempel: Prosjektoppfølging

Fokus på det overordnede formålet er nødvendig, men det kan være for abstrakt for mange av de daglige bruksområder. Derfor er det nødvendig med et hierarki av drivere for å gjøre det mer praktisk. For det første defineres begrunnelsen og fordelene ved prosjektet basert på det endelige formål, og da vil du ha eksplisitte og implisitte mål for prosjektvariabler (f.eks. tid, kostnad og kvalitet) for å tilfredsstille begrunnelsen, som igjen vil tilfredsstille det overordnede formål. Disse er lavere nivåer som er nyttige for mange av våre daglige oppgaver.

Når det gjelder oppfølging, vil overvåking av de daglige oppgavene i prosjektet bli gjort ved å bruke det laveste nivået av variabler, fordi det kanskje ikke er mulig å spore det endelige målet. I dette tilfellet bør du fortsatt ha formålet med deg i tankene: hva er formålet med overvåking?

Et normalt og akseptabelt svar er å se om vi er i henhold til plan, og hvis ikke, må vi initiere aksjoner for å bringe oss tilbake på planen eller justere målene og se om det fortsatt kan tilfredsstille det endelige målet. Våre målinger bør derfor kunne hjelpe med denne vurderingen, og de riktige målingene er prognoser for variablene ved ferdigstillelse; for eksempel når kan vi fullføre prosjektet? Hvor mye penger trenger vi for å fullføre prosjektet?

Alle andre målinger, for eksempel de planlagte og faktiske verdiene til dags dato, er bare midlertidige verdier som du trenger for å beregne prognosene, ikke de endelige verdiene du bruker til styringsformål.

Eksempel: Dokumenter

Uansett hvilken utviklingsmetode du bruker i prosjektet, er planlegging alltid nødvendig. Det viktige spørsmålet er detaljnivået i hver type plan. Hvis det ikke er nok detalj i planen, vil planen ikke kunne bidra med nok, og gjennomføringen av prosjektet vil være basert på ad hoc-beslutninger snarere enn integrerte og helhetlige. På den annen side prøver mange mennesker å være påpasselige og legge for mye detalj i planen, noe som gjør det for vanskelig å forberede og vedlikeholde, og dermed blir planen for rigid for prosjektets usikkerhet. Som et resultat blir planen urealistisk og ubrukelig.

Den beste måten å bestemme om detaljnivået er riktig, er å ha en hensikt i tankene for hvert element i planen. Hvis du for eksempel vurderer å legge til ressurser til planen, bør du ha en hensikt for det: Hvordan skal du bruke den? Hvordan vil det hjelpe prosjektet? Hvor mye innsats vil det ta? Og er det verdt det?

Det handler noen ganger om å avgjøre om du vil ha et visst element i dine planer, og noen ganger om hvordan du vil planlegge eller forberede noe. Enten det er et business case, et prosjekts charter eller en rapport: Du bør fortsatt spørre deg selv hvorfor du forbereder dokumentet og hvordan det kan hjelpe prosjektet.

Å lete etter en “mal” er det motsatte av å gjøre noe basert på et formål.

Eksempel: Statusrapportering

Det er vanlig å ha veldig lange statusrapporter i mange prosjekter. Basert på denne NUP, bør vi spørre oss hva formålet med rapporten er og hvordan vi kan oppnå det formålet, uansett hva de fleste andre velger å gjøre.

Det kan ofte være tilstrekkelig å lage enkle en-siders rapporter som interessentene dine virkelig leser og forstår i stedet for lange rapporter. Det handler om å være oppmerksom på formålet med det du gjør.

Hvis du forbereder en-siders rapporter, kan enkelte mennesker motsette seg din fremgangsmåte og tenke at du ikke har et “riktig” overvåkingssystem på plass. I praksis oppretter dette et annet formål for deg (foruten det første formålet, som hjelper interessenter å forstå statusen til prosjektet), og for å tilfredsstille det, kan du bare lage en annen type rapport som er veldig lang. Du vil imidlertid ikke blande det med den første rapporten, fordi disse to formålene ikke er de samme.

Eksempel: Business case og Prosjekt charter

Forberedelse av dokumenter som et business case og et prosjekt charter er vanligvis en kjedelig, fruktløs, byråkratisk nødvendighet for de fleste av oss, mens disse dokumentene alle har gyldige formål som gjelder for de fleste prosjekter. Hvis du prøver å finne en “mal” og fyller den inn, er arbeidet bare bortkastet; mens hvis du i stedet kan sjekke den virkelige hensikten med disse dokumentene, se om og hvordan de kan være nyttige i prosjektet ditt, og utarbeide dokumentet på en slik måte du liker, for å tilfredsstille formålene: det vil være det riktige dokumentet for ditt prosjekt.

Det kan være vanskelig å tenke på alle scenarier og alle områder som bør være en del av slike grunnleggende styringsdokumenter, og kanskje mangler du noe viktig. For å unngå at du mangler noe viktig, kan du sjekke for å se hvilke ressurser som inngår i PRINCE2^®, PMBOK^® Guide, P3.express og DSDM^®suggest, og deretter vurdere disse forslagene basert på formålet.

Eksempel: Prosjektevaluering

Selv om prosjektet har et bestemt formål, og vi kan vurdere dette formålet gjennom hele prosjektet, er realiseringen av formålet hovedsakelig basert på prognoser i prosjektet. Vi bør imidlertid ikke glemme dette når prosjektet er ferdig. Det er viktig å sjekke realiseringen av målene etter at prosjektet er ferdig, fordi

• vi kan se hvordan de endelige målene ble nådd og lære av det for fremtidige prosjekter, og
• noen ganger blir målene nådd bare hvis vi utfører noen ekstra oppgaver etter prosjektets gjennomføring, og det å forstå behovet for disse ekstra oppgavene krever overvåking.

Prosjektevaluering er en viktig del av å være målfokusert. Det er hovedsakelig ansvaret for program- og porteføljestyringssystemer, og fordi de fleste selskaper ikke har slike systemer tilgjengelig, blir denne delen vanligvis forsømt. Derfor legger metoder som P3.express og DSDM^® denne delen til i sine prosjektledelsesmetoder.

Eksempel: Enkelhet

Verden er kompleks og kaotisk, men våre modeller er kun abstrakte tilnærminger som reflekterer deler av verden, og dermed kan de være for enkle. På den annen side fungerer enkle systemer vanligvis bedre, fordi vi kan være fokusert på hovedideen.

Mange av oss prøver å få bedre resultater ved å legge til kompleksitet i våre systemer, i håp om at det vil samsvare med verdens kompleksitet, selv om det i praksis gjør systemet vanskelig å jobbe med og vanligvis blokkerer oss fra å tilfredsstille formålet.

Eksempel: Skreddersøm

Et stykke programvare for streaming av musikk har en helt annen tilstand enn den som skal brukes til utstyr på et sykehus, eller fra et program som skal brukes i en satellitt hvor tanken er at det skal fungere tilfredsstillende i mange år uten å krasje. Det er stor forskjell på å bygge en sommer villa, sammenlignet med en brannstasjon eller et prosessanlegg.

Når du har formålet med deg i tankene, vil du bedre forstå hvordan du kan skreddersy systemene og artefaktene for de ulike prosjektene.

▼ PDF