Fejl, problemer og risici: hvorfor skelnen er vigtig
De fleste projektteams bruger disse tre ord i flæng. Det er en fejltagelse. En fejl, et problem og en risiko er tre forskellige typer problemer der kræver tre forskellige typer respons. At behandle dem ens fører til fejlallokeret ressourceforbrug, uhensigtsmæssige følgevirkninger og — afgørende — giver Kamæleoner og Rooster præcis den tvetydighed de har brug for til at forvandle et lille teknisk problem til en politisk begivenhed.
Henning Christiansen trækker en skarp sondring i Project Management: The Red Pill:
Casestudie: Heathrow Terminal 5 — når det tekniske lykkes og det operationelle fejler
Heathrow Terminal 5 åbningsdag (2008)
Heathrow Terminal 5 var et af Europas mest ambitiøse lufthavnsinfrastrukturprojekter. Det blev leveret til tiden og inden for budgettet. Det er hyppigt citeret som en byggesucces. Bygningen var færdig. Ingeniørarbejdet var fejlfrit. Og så skete åbningsdagen.
Projektteamet undervurderede kraftigt kompleksiteten i at gøre terminalen operationel. Personalet var ukendt med layoutet. Det automatiserede bagagesystem var aldrig blevet testet i fuld skala under reelle betingelser.
- Personalets beredskab var aldrig kategoriseret som en risiko — ingen spurgte hvad der sker hvis personalet ikke kan navigere terminalen på dag ét
- Bagagesystemet blev aldrig stresstestet — integrationstest og belastningstest blev behandlet som underordnede punkter
- Eksternt miljø blev prioriteret over operationel beredskab — pres om offentlig lancering tilsidesatte interne kvalitetstjek
- Ingen modellerede afhængighederne — personaleviden, bagagesystemydelse og flyoperationer blev behandlet som uafhængige; det var de ikke
Fejlfri byggeri betyder lidt hvis operationelle systemer og slutbruger-beredskab ikke er indlejret i projektmodellen. Problemer der ikke er synlige i modellen vil dukke op på åbningsdagen.
Hvorfor projektmodeller forebygger de fleste fejl og problemer
Det er den indsigt der adskiller Christiansens tilgang fra standard fejlhåndteringsrammer: de fleste fejl og problemer er ikke tilfældige hændelser. De er den forudsigelige konsekvens af dårligt forståede afhængigheder.
Traditionelle planlægningsredskaber — WBS, opgavelister, Agile user stories — er fremragende til at spore hvad der skal gøres. Men de lider under en kritisk begrænsning: de bevarer ikke forbindelsen mellem mål, opgaver og relationerne mellem komponenter.
"Jo hurtigere du kan identificere kaskadeeffekter, jo hurtigere kan teamet justere og reagere på ændringer på en smart og effektiv måde. Selv en tilsyneladende lille ændring kan have vidtrækkende konsekvenser i et projekt."
— Henning Christiansen, Project Management: The Red Pill
Hvad en projektmodel er — og hvad den giver dig
En projektmodel er en struktureret repræsentation af enhver betydningsfuld komponent i projektet, med tre elementer defineret for hver:
- Egenskaber — de definerende karakteristika for komponenten (dimensioner, ydeevnekriterier, acceptstandarder)
- Handlinger — hvad komponenten gør (sender en besked, behandler en betaling, åbner en dør, autentificerer en bruger)
- Afhængigheder — hvad komponenten er afhængig af og hvad der er afhængig af den
En lille justering af sædepositionen kan kræve ændringer til dørplaceringen. Den dørændring kan kaskade ind i ændringer til bilens eksteriørdesign. I en traditionel opgaveliste er den kaskade usynlig indtil nogen opdager den midt i bygningen. I en projektmodel er den synlig inden nogen tager et redskab op.
Afhængigheder: den primære kilde til uventede fejl
Forståelse af afhængigheder er det enkelt mest virkningsfulde en projektteam kan gøre for at reducere fejl og problemer. Christiansen identificerer tre grunde til at afhængigheder har så stor betydning:
- De påvirker timing — én opgave venter måske på en anden. Når den afhængighed er udokumenteret, starter folk opgaver inden forudsætningerne er klar og producerer omarbejde.
- De påvirker risiko — hvis en afhængighed fejler, kan hele den nedstrøms proces bryde ned.
- De hjælper med at styre ændringer — når afhængigheder er kortlagt, udløser en ændringsanmodning automatisk synlighed i alt hvad den ændring vil påvirke.
Agile-metoder har ofte teams der udfører delopgaver simultant, selv når disse er indbyrdes afhængige. Dette virker når projektlederen bevarer et klart overblik over det store billede. Når det billede mistes — når parallelle spor kører uden en delt model — skaber omarbejdet ved integrationspunktet flere fejl end en sekventiel tilgang ville have gjort.
Når fejl og problemer opstårr: to-vejs-responsen
Selv det bedst modellerede projekt vil have fejl. Den afgørende faktor er hvordan du reagerer.
Fejl som Monkey Poker: den politiske dimension
Fejl, problemer og risici er muligheder for Kamæleoner og Rooster til at spille Monkey Poker. Disse individer kan udnytte problemer til at skifte skylden, opnå synlighed eller undergrave andre til personlig vinding.
Når en fejl opdages, er Kamæleonens første træk ofte at forstærke krisen — ikke at løse den. Roosters version er anderledes men ligeså skadelig: de bruger fejlen som mulighed for at forfølge teknisk interessante problemer der ikke er den højeste prioritet.
Denne artikel refererer til de politiske dynamikker — Chameleons, Roosters, Monkey King, Honey Bees, Parrots og Unicorn-PM — der løber under ethvert projekt. Fuld guide: Interessentstyring og Monkey Poker →
Hvis Monkey Poker eskalerer en fejl for voldsomt, vil det til sidst inddrage Monkey King. En projektleder der demonstrerer klar kontrol over problemet — med en modelbaseret forståelse af omfang og impact, en dokumenteret løsningsplan og transparent kommunikation — gør Monkey Poker-trækket for risikabelt. Kamæleonen eller Hanen der eskalerede bliver personen der forstyrrede Monkey King. De taber.
Forebyggelse: sådan bygger du et projekt der producerer færre fejl
Definer enhver model inden arbejdet begynder
For enhver model og undermodel i projektet skal følgende dokumenteres: hvilket mål eller formål den understøtter, hvilke kompetencer der kræves, tidsestimatet for udvikling og eventuelle hårde deadlines.
Kortlæg afhængigheder eksplicit — og gennemgå dem ved hvert gate
Afhængigheder er ikke stabile over projektets levetid. Spørg ved hvert fasegate: er der opstået nye afhængigheder? Har antagne afhængigheder vist sig ikke at eksistere? Har nogen afhængigheder ændret karakter?
Brug modellen til at evaluere enhver ændringsanmodning inden du accepterer den
Enhver ændringsanmodning bør udløse en modelgennemgang: hvilke komponenter påvirker denne ændring? Hvad er de nedstrøms konsekvenser?
Registrér faktisk vs. estimeret tid på enhver opgave
Tidsestimeringsdata er det mest underudnyttede aktiv i projektledelse. Mønstre — opgaver der konsekvent overskrider estimater — er næsten altid et symptom på underspecificeret arbejde, skjulte afhængigheder eller et teammedlem der kæmper.
Hvad man skal — og hvad man skal undgå
- Skelnen klart mellem fejl, problemer og risici — hver kræver en anden respons
- Byg en projektmodel med egenskaber, handlinger og afhængigheder inden opgaver planlægges
- Kortlæg alle afhængigheder eksplicit og gennemgå dem ved hvert fasegate
- Brug modellen til at vurdere kaskadeimpakten af enhver ændringsanmodning
- Registrér faktisk vs. estimeret tid på enhver opgave
- Identificér berørte modelkomponenter inden ekstern kommunikation når en fejl opdages
- Stabilisér det eksterne miljø først — kommunikér efter forståelse, ikke før
- Kommunikér proaktivt til interessenter inden de hører via uformelle kanaler
- Oprethold streng scope-frysning under problemløsning
- Dokumentér enhver fejl, ethvert problem og enhver risiko — og deres løsning
- Behandl ikke fejl, problemer og risici som udskiftelige
- Stol ikke udelukkende på opgavelister — de viser ikke afhængigheder
- Kommunikér ikke et problem eksternt inden du forstår dets omfang og løsning
- Tillad ikke Kamæleoner at bruge en fejl til at skubbe nye funktioner igennem
- Lad ikke Rooster bruge forstyrrelse som dækning til tekniske afstikkere
- Spring ikke slutbruger- og operationelt beredskabstest over — Heathrow T5 er advarslen
- Behandl ikke parallel udførelse i Agile som en undskyldning for at ignorere afhængigheder
- Eskaler ikke til Monkey King uden en klar løsningsplan
- Accepter ikke ændringsanmodninger under en krise uden fuld modelbaseret impaktvurdering
- Lad ikke faktisk vs. estimeret tid stå uregistreret
Modellen er diagnostikken, ikke kun planen
Unicorn-PM behandler ikke projektmodellen som et planlægningsartefakt der bliver irrelevant under udførelse. De bruger den som et levende diagnostisk redskab. Når en fejl rapporteres, er det første træk at åbne modellen og identificere hvilke komponenter der er berørte — inden nogen kommunikation sker og inden nogen løsning foreslås.
Fakta som forsvar mod Monkey Poker
Når fejl skaber politisk pres — og det gør de altid — reagerer Unicorn-PM med fakta fra modellen: hvilke specifikke komponenter der er berørte, hvad den realistiske indsats til løsning er, hvad de nedstrøms konsekvenser af de foreslåede workarounds er.
- Dokumentér ethvert problem, enhver løsning og enhver beslutning — papirstien er både en læringsressource og et politisk skjold
- Ros teamet offentligt når en fejl opdages og fixes godt — opdagelsen af et problem er ikke en fiasko; det er kvalitetssikring der virker
- Forbliv rolig når Monkey Poker eskalerer around en fejl
- Forstærk Monkey Kings interesser gennem transparent, modelbaseret kommunikation — hold dem trygge, hold dem sovende
Fejl- og problemstyring i Proglar
Proglar forbinder projektmodellen til fejl- og problemregistret, hvilket betyder at når et problem logges er dets relation til de berørte modelkomponenter øjeblikkeligt synlig.
Færre fejl starter med en bedre model
Proglar forbinder din projektmodel til dit fejlregister, dine afhængigheder til din ændringsimpaktanalyse og dine faktiske til dine estimater. Prøv gratis i 30 dage.