Definer Behov

Det første steget i et prosjekt er å definere hva man ønsker å oppnå med prosjektet. Det er i denne fasen man definerer rammene for de viktigste faktorene Tid, Kost og Kvalitet. Disse faktorene er meget viktig igjennom hele prosjektet..

Restriksjonsfaktorene

Om man vil øke kvaliteten, må man endre kost og/eller tid. Om man vil endre kost må man endre kvalitet og/eller tid. Om man ønsker å endre tiden må man endre kvalitet og/eller kost. Dette konseptet kalles en restriksjonstrekant (Triangle of constraints) og definerer at et prosjekt har begrensninger og at om man endrer en av faktorene, påvirker dette andre sider av prosjektet. Figur 6 viser trekanten

Eks. Et prosjekt er halvveis gjennomført basert på tid. Eier av prosjektet vil plutselig at alt leveres 2 mnd før planlagt levering. Prosjekt gjennomføringstiden er nå kortere, da står man ovenfor problemet med å balansere mellom de to andre faktorene kost og kvalitet. Ja vi kan levere om vi setter inn dobbelt så mange ressurser, men det koster dobbelt så mye. Eller, vi kan gjennomføre dette på den nye tiden, med de samme ressursene, men da blir kvaliteten lavere på det som leveres eller man leverer halvparten så mye som planlagt. Nå har vi introdusert en fjerde faktor, nemlig leveringsomfang (eng=scope). Å endre leveringsomfang er å direkte endre målet med prosjektet.

Balansering av restriksjonsfaktorene

Så hva er best å gjøre i forrige eksempel? Vel det er her prosjektleder må bruke alle kunnskaper og erfaringer til å balansere de mål som er satt. Om man allerede fra starten definerer en rangering av faktorene Tid, Kost og Omfang, har man en mulighet for å analysere problemet. Med andre ord, finn ut hva som er viktigst i prosjektet. Figur 7 viser en enkel mal for balansering hvor man bare kan definere en gruppe en gang. Dvs. Man kan ikke rangere både tid og kost som Høy. Dette tvinger fram en rangering som gjør en balansering av faktorene lettere i prosjektet.

Husk det er kunden som skal definerer denne rangeringen.

Når man møter på problemer i prosjektet og må ta en avgjørelse om tid, kost og omfang er det viktig å vite hvor man skal begynne. Om tid er viktigere en kost og kost er viktigere en leveringsomfang er saken klar, man fokuserer på tid og tar den økte kosten samt reduserer leveringsomfang. Men om dette ikke er definert vet man ikke hvordan balansegangen skal gjennomføres. Dette er ikke unikt, det skjer hver dag. Det er ikke uvanlig at en prosjektleder møtes med, ”lever samme til lavere kost på halve tiden”, da har man definitivt et problem. Dette problemet er i stor grad knyttet til det ansvaret en prosjektleder har til å forklare prosjekt eier/kunde hva som er mulig og det er ikke lett når man jobber med økonomer med ”blåruss mentalitet = Økt kvalitet + redusert pris = Sant”.

En prosjektleder har en forpliktelse til å si klart fra om hvilke muligheter som finnes og hva resultatene er av de valg man gjør, men det er ikke alltid lett. På den annen side er det også prosjektleders plikt å være kreativ nok til å kunne redefinere prosjektet slik at man kan få en bedre balanse. Man ansetter ikke en prosjektleder om alt går som smurt hver gang, problemer er selve årsaken til att prosjektledere har jobb. Outsourcing er et godt eksempel på eksenter balansering av faktorer, man øker antall ressurser, men holder samme kost nivå. At risikoen for problemer øker for prosjektet er en annen sak som prosjektleder må håndtere. Endringer i forutsetninger gir mange en følelse av kaos (ref: Kaospilot), og dette er ikke alltid lett å håndtere på en strukturert måte.

Definisjonsprosessen:

Generelt:

For å kunne være sikker på at man har forstått hva som egentlig ønskes er det lurt å lage et Prosjektforslag. Forslaget er bare en enkel struktur for å forstå hva som egentlig er ønsket på et tidlig stadige. En annen grunn for å formalisere dette er at mange prosjekt starter med en enkel oppfordring eller kommentar, ”kjør et prosjekt” og mye tid går med på å sett i gang halvbakte ideer. Ved at vedkommende som kom med ideen skal føle tilhørighet og kunne trekke tilbake ideer som ikke var godt gjennomtenkt tidlig i fasen er en tredje grunn for ønsket om et formelt Prosjektforslag. Det viser seg at mange har lett for å starte noe, men litt verre for å kjøre igjennom når de ser det samme formalisert og spesielt om man også må signere under på sine ideer.

Prosessflyt: Figur 8

Prosess 1.1

Inn:

En ide til et prosjekt

Roller:

Kunde(100 %): Den som kommer med ideen eller kravet om et prosjekt er også den som skal lage Prosjektforslaget og signere det.

Verktøy: Prosjektforslag.doc

Ut:

Et signert Prosjektforslag som forklarer hva som er ønsket av den som kom med ideen. Det viktige er ikke malen i seg selv, men den formelle informasjon som vist i tabellen.

Prosjektdata: Dato, Prosjekt kunde, Prosjektleder, Prosjekt navn, Prosjekt nummer (ikke brukt av alle)
Ide / Problem: Beskriv grunnen for prosjekt behovet
Fordeler/Påvirkning: Hvilke fordeler/påvirkninger gir dette prosjektet organisasjonen. Strategi som støttes av prosjektet og hvordan
Involvering: Hvem tenkes involvert i prosjektet
Restriksjonsprioritering: Balanser faktorene Tid, Kost og Omfang/Kvalitet
Godkjennelse: Godkjent av den som kom med ideen eller problemet

Prosess 1.2

Inn:

Et signert Prosjektforslag

Roller:

Prosjektleder(90 %): Vanligvis vil Prosjektforslaget være første møte med et potensielt prosjekt. Men det er prosjektleders ansvar å se til at Prosjektforslaget blir fylt ut og signert av den som er definert som kunde før man begynner å jobbe på noe annet.
Kunde(10 %): Kunde avklarer om det er noen uklarheter

Ut:

Klargjøring for Initieringsfasen

Initier - Definer - Planlegg - Gjennomfør - Avslutt