Buggar, problem och risker: varför distinktionen spelar roll
De flesta projektteam använder dessa tre ord omväxlande. Det är ett misstag. En bugg, ett problem och en risk är tre olika typer av problem som kräver tre olika typer av respons.
Henning Christiansen drar en skarp distinktion i Project Management: The Red Pill:
Fallstudie: Heathrow Terminal 5
Heathrow Terminal 5 öppningsdag (2008)
Heathrow Terminal 5 levererades i tid och inom budget. Byggnaden var klar. Ingenjörsarbetet var felfritt. Och sedan hände öppningsdagen.
Projektteamet underskattade kraftigt komplexiteten i att göra terminalen operationell. Personal kände inte till layouten. Bagagesystemet hade aldrig testats i full skala.
- Personalens beredskap kategoriserades aldrig som en risk
- Bagagesystemet stresstestades aldrig
- Externt tryck prioriterades över operationell beredskap
- Ingen modellerade beroendena — personal, bagagesystem och flygoperationer behandlades som oberoende
Felfritt byggande betyder lite om operationella system och slutanvändarens beredskap inte är inbyggda i projektmodellen.
Varför projektmodeller förebygger de flesta buggar
De flesta buggar och problem är inte slumpmässiga händelser. De är den förutsägbara konsekvensen av dåligt förstådda beroenden.
Traditionella planeringsverktyg — WBS, uppgiftslistor, Agile user stories — bevarar inte kopplingen mellan mål, uppgifter och relationer mellan komponenter.
"Ju snabbare du kan identifiera kaskadeffekter, desto snabbare kan teamet anpassa sig och reagera på förändringar på ett smart och effektivt sätt. Även en till synes liten förändring kan ha vittgående konsekvenser i ett projekt."
— Henning Christiansen, Project Management: The Red Pill
Vad en projektmodell är — och vad den ger dig
En projektmodell är en strukturerad representation av varje viktig komponent i projektet, med tre element definierade för varje:
- Egenskaper — komponentens definierande egenskaper
- Handlingar — vad komponenten gör
- Beroenden — vad komponenten förlitar sig på och vad som förlitar sig på den
En liten justering av sätets position kan kräva ändringar i dörrarnas placering. I en traditionell uppgiftslista är den kaskaden osynlig. I en projektmodell är den synlig innan någon tar upp ett verktyg.
Beroenden: den primära källan till oväntade buggar
Att förstå beroenden är det enskilt mest verkningsfulla ett projektteam kan göra för att minska buggar och problem.
- De påverkar timing — en uppgift kanske väntar på en annan. Odokumenterade beroenden leder till omarbete.
- De påverkar risk — om ett beroende misslyckas kan hela processen bryta ihop.
- De hjälper att hantera förändringar — kartlagda beroenden gör kaskadens omfång synligt.
Agile-metoder har ofta team som utför deluppgifter simultant, även när de är ömsesidigt beroende. Detta fungerar när projektledaren behåller en klar bild av helheten. När den bilden förloras skapar omarbetet vid integrationspunkterna fler buggar.
När buggar och problem anländer: tvåspårsresponsen
Även det bäst modellerade projektet kommer att ha buggar. Den avgörande faktorn är hur du reagerar.
Buggar som Monkey Poker: den politiska dimensionen
Buggar, problem och risker är möjligheter för Chameleons och Roosters att spela Monkey Poker. Dessa individer kan utnyttja problem för att skifta skuld, vinna synlighet eller underminera andra.
Chameleon ser en distraherad stämning som möjlighet att driva igenom nya funktioner. Rooster använder buggar som täckning för att arbeta med tekniskt intressanta tangenter.
Den här artikeln refererar till de politiska dynamikerna under varje projekt. Fullständig guide: Intressenthantering och Monkey Poker →
En projektledare som demonstrerar tydlig kontroll av problemet — med en modellbaserad förståelse av omfång, en dokumenterad lösningsplan och transparent kommunikation — gör Monkey Poker-draget för riskabelt.
Förebyggande: bygg ett projekt som producerar färre buggar
Definiera varje modell innan arbetet börjar
För varje modell och delmodell ska dokumenteras: vilket mål det stödjer, vilka kompetenser som krävs, tidsestimatet och eventuella hårda deadlines.
Kartlägg beroenden explicit — och granska dem vid varje gate
Beroenden är inte stabila över projektets livslängd. Fråga vid varje fasgate: har nya beroenden uppstått?
Använd modellen för att utvärdera varje ändringsförfrågan
Varje ändringsförfrågan bör utlösa en modellgranskning: vilka komponenter påverkar denna förändring?
Registrera faktisk vs. estimerad tid på varje uppgift
Mönster — uppgifter som konsekvent överskrider estimat — är nästan alltid ett symptom på underspecificerat arbete eller dolda beroenden.
Vad man ska göra — och vad man ska undvika
- Skilja tydligt mellan buggar, problem och risker
- Bygg en projektmodell med egenskaper, handlingar och beroenden
- Kartlägg alla beroenden explicit och granska dem vid varje fasgate
- Använd modellen för att bedöma kaskadinverkan av ändringsförfrågningar
- Registrera faktisk vs. estimerad tid på varje uppgift
- Identifiera berörda modellkomponenter innan extern kommunikation
- Stabilisera den externa miljön först
- Kommunicera proaktivt till intressenter
- Upprätthåll strikt scope-frys under problemlösning
- Dokumentera varje bugg, problem och risk
- Behandla inte buggar, problem och risker som utbytbara
- Förlita dig inte enbart på uppgiftslistor
- Kommunicera inte ett problem externt innan du förstår dess omfång
- Tillåt inte Chameleons att använda en bugg för att driva igenom nya funktioner
- Låt inte Roosters använda störningar som täckning
- Hoppa inte över slutanvändar- och operationell beredskapstestning
- Behandla inte parallell utförande i Agile som ursäkt för att ignorera beroenden
- Eskalera inte till Monkey King utan en lösningsplan
- Godta inte ändringsförfrågningar under en kris utan bedömning
- Lämna inte faktisk vs. estimerad tid oregistrerad
Modellen är diagnostiken, inte bara planen
Unicorn PM behandlar inte projektmodellen som en planeringsartefakt som blir irrelevant under utförande. De använder den som ett levande diagnostiskt verktyg.
Fakta som försvar mot Monkey Poker
När buggar skapar politiskt tryck reagerar Unicorn PM med fakta från modellen: vilka komponenter berörs, vad är den realistiska insatsen för lösning.
- Dokumentera varje problem, varje lösning och varje beslut
- Berömma teamet offentligt när en bugg hittas och åtgärdas väl
- Förbli lugn när Monkey Poker eskalerar kring en bugg
- Förstärk Monkey Kings intressen genom transparent, modellbaserad kommunikation
Bugg- och problemhantering i Proglar
Proglar kopplar projektmodellen till bugg- och problemregistret, vilket innebär att när ett problem loggas är dess relation till de berörda modellkomponenterna omedelbart synlig.
Färre buggar börjar med en bättre modell
Proglar kopplar projektmodellen till felregistret, beroenden till ändringskonsekvensanalys och faktiska till estimat. Prova gratis i 30 dagar.