Feil, problemer og risikoer: hvorfor skillet er viktig
De fleste prosjektteam bruker disse tre ordene om hverandre. Det er en feil. En bug, et problem og en risiko er tre ulike typer problemer som krever tre ulike typer respons.
Henning Christiansen trekker et skarpt skille i Project Management: The Red Pill:
Casestudie: Heathrow Terminal 5
Heathrow Terminal 5 åpningsdag (2008)
Heathrow Terminal 5 ble levert i tide og innenfor budsjettet. Bygningen var ferdig. Ingeniørarbeidet var feilfritt. Og så skjedde åpningsdagen.
Prosjektteamet undervurderte kraftig kompleksiteten i å gjøre terminalen operasjonell. Personalet var ukjent med layoutet. Bagasjesystemet hadde aldri blitt testet i full skala.
- Personalets beredskap ble aldri kategorisert som en risiko
- Bagasjesystemet ble aldri stresstestet
- Eksternt miljø ble prioritert over operasjonell beredskap
- Ingen modellerte avhengighetene — personalets kunnskap, bagasjesystemytelse og flyoperasjoner ble behandlet som uavhengige
Feilfritt bygg betyr lite hvis operasjonelle systemer og sluttbruker-beredskap ikke er innebygd i prosjektmodellen.
Hvorfor prosjektmodeller forebygger de fleste feil
De fleste feil og problemer er ikke tilfeldige hendelser. De er den forutsigbare konsekvensen av dårlig forståtte avhengigheter.
Tradisjonelle planleggingsverktøy — WBS, oppgavelister, Agile user stories — bevarer ikke forbindelsen mellom mål, oppgaver og relasjoner mellom komponenter.
"Jo raskere du kan identifisere kaskadeeffekter, jo raskere kan teamet justere og reagere på endringer på en smart og effektiv måte. Selv en tilsynelatende liten endring kan ha vidtrekkende konsekvenser i et prosjekt."
— Henning Christiansen, Project Management: The Red Pill
Hva en prosjektmodell er — og hva den gir deg
En prosjektmodell er en strukturert representasjon av enhver betydningsfull komponent i prosjektet, med tre elementer definert for hver:
- Egenskaper — de definerende karakteristikkene til komponenten
- Handlinger — hva komponenten gjør
- Avhengigheter — hva komponenten er avhengig av og hva som er avhengig av den
En liten justering av seteposisjonen kan kreve endringer i dørplasseringen. I en tradisjonell oppgaveliste er den kaskaden usynlig. I en prosjektmodell er den synlig før noen tar opp et verktøy.
Avhengigheter: den primære kilden til uventede feil
Forståelse av avhengigheter er det enkelt mest virkningsfulle et prosjektteam kan gjøre for å redusere feil og problemer.
- De påvirker timing — én oppgave venter kanskje på en annen. Udokumenterte avhengigheter fører til omarbeid.
- De påvirker risiko — hvis en avhengighet feiler, kan hele prosessen bryte ned.
- De hjelper med å styre endringer — kartlagte avhengigheter gjør kaskadens omfang synlig.
Agile-metoder har ofte team som utfører deloppgaver simultant, selv når de er gjensidig avhengige. Dette fungerer når prosjektlederen bevarer et klart bilde av helheten. Når det bildet mistes, skaper omarbeidet ved integrasjonspunktet flere feil enn en sekvensiell tilnærming ville ha gjort.
Når feil og problemer ankommer: to-spors-responsen
Selv det best modellerte prosjektet vil ha feil. Den avgjørende faktoren er hvordan du reagerer.
Feil som Monkey Poker: den politiske dimensjonen
Feil, problemer og risikoer er muligheter for Chameleons og Roosters til å spille Monkey Poker. Disse individene kan utnytte problemer til å skifte skyld, oppnå synlighet eller undergrave andre.
Chameleon ser en distrahert stemning som mulighet til å skubbe nye funksjoner gjennom. Rooster bruker feil som dekning til å jobbe med teknisk interessante tangenter.
Denne artikkelen refererer til de politiske dynamikkene under ethvert prosjekt. Fullstendig guide: Interessentstyring og Monkey Poker →
En prosjektleder som demonstrerer klar kontroll over problemet — med en modellbasert forståelse av omfang, en dokumentert løsningsplan og transparent kommunikasjon — gjør Monkey Poker-trekket for risikabelt.
Forebygging: slik bygger du et prosjekt med færre feil
Definer enhver modell før arbeidet begynner
For enhver modell og undermodell skal følgende dokumenteres: hvilket mål den støtter, hvilke ferdigheter som kreves, tidsestimatet og eventuelle harde frister.
Kartlegg avhengigheter eksplisitt — og gjennomgå dem ved hvert gate
Avhengigheter er ikke stabile over prosjektets levetid. Spør ved hvert fasegate: er det oppstått nye avhengigheter?
Bruk modellen til å evaluere enhver endringsforespørsel
Enhver endringsforespørsel bør utløse en modellgjennomgang: hvilke komponenter påvirker denne endringen?
Registrer faktisk vs. estimert tid på enhver oppgave
Mønstre — oppgaver som konsekvent overskrider estimater — er nesten alltid et symptom på underspecifisert arbeid eller skjulte avhengigheter.
Hva man skal — og hva man skal unngå
- Skille klart mellom feil, problemer og risikoer
- Bygg en prosjektmodell med egenskaper, handlinger og avhengigheter
- Kartlegg alle avhengigheter eksplisitt og gjennomgå dem ved hvert fasegate
- Bruk modellen til å vurdere kaskadevirkningene av endringsforespørsler
- Registrer faktisk vs. estimert tid på enhver oppgave
- Identifiser berørte modellkomponenter før ekstern kommunikasjon
- Stabiliser det eksterne miljøet først
- Kommuniser proaktivt til interessenter
- Oppretthold streng scope-frysing under problemløsning
- Dokumenter enhver feil, ethvert problem og enhver risiko
- Ikke behandle feil, problemer og risikoer som utskiftelige
- Ikke stol utelukkende på oppgavelister
- Ikke kommuniser et problem eksternt før du forstår omfanget
- Ikke la Chameleons bruke en feil til å skubbe nye funksjoner
- Ikke la Roosters bruke forstyrrelser som dekning
- Ikke hopp over sluttbruker- og operasjonell beredskapstest
- Ikke behandle parallell utførelse i Agile som unnskyldning for å ignorere avhengigheter
- Ikke eskaler til Monkey King uten en løsningsplan
- Ikke godta endringsforespørsler under en krise uten vurdering
- Ikke la faktisk vs. estimert tid stå uregistrert
Modellen er diagnostikken, ikke bare planen
Unicorn-PM behandler ikke prosjektmodellen som et planleggingsartefakt som blir irrelevant under utførelse. De bruker den som et levende diagnostisk verktøy.
Fakta som forsvar mot Monkey Poker
Når feil skaper politisk press reagerer Unicorn-PM med fakta fra modellen: hvilke komponenter er berørte, hva er den realistiske innsatsen for løsning.
- Dokumenter hvert problem, enhver løsning og enhver beslutning
- Ros teamet offentlig når en feil oppdages og fikses godt
- Forblir rolig når Monkey Poker eskalerer rundt en feil
- Forsterk Monkey Kings interesser gjennom transparent, modellbasert kommunikasjon
Feil- og problemstyring i Proglar
Proglar kobler prosjektmodellen til feil- og problemregisteret, noe som betyr at når et problem logges er forholdet til de berørte modellkomponentene øyeblikkelig synlig.
Færre feil starter med en bedre modell
Proglar kobler prosjektmodellen til feilregisteret, avhengigheter til endringsimpaktanalyse og faktiske til estimater. Prøv gratis i 30 dager.