Flowchart for ændringsanmodninger i projekter (scope, tid, økonomi)

Hvad er flowchart for ændringsanmodninger i projekter (scope, tid, økonomi)?

En ændringsanmodning i et projekt beder om at ændre noget, der allerede er aftalt: omfanget, økonomien eller datoerne i den godkendte baseline. Det er netop dét, der adskiller den fra almindelig omplanlægning. At bytte rundt på opgaver, flytte en person mellem arbejdsstrømme eller absorbere to dages forsinkelse inde i bufferen er projektlederens arbejde og kræver ingen anmodning. Denne proces begynder, når nogen beder om noget, baselinen ikke lover i dag, og den slutter enten med en baseline, der siger noget andet, eller med en anmodning, der er lukket med begrundelsen registreret.

Det her er projektændringsstyring: ikke ændringsstyring på it-services. Handler jeres beslutning om, hvorvidt en ændring må frigives i drift, med CAB, ændringskalender, nedetidsvindue og rollback-plan, så er det flowchartet for ændringsstyring (ITIL) på /da/templates/aendringsstyring-itil-proces og den generelle change control-proces på /da/templates/aendringsstyring-proces, der dækker det område. Spørgsmålene her er af en anden art: hvad ændringen koster, hvad den flytter, hvem der finansierer den, og om business casen stadig holder. Det er heller ikke forandringsledelse i den menneskelige forstand, som ligger bag modeller som ADKAR, og det er ikke en fasegate. Skal I beslutte, om I overhovedet går videre ved afslutningen af en fase frem for at ændre baselinen, så brug go/no-go-beslutningsprocessen på /da/templates/go-no-go-beslutningsproces.

To beslutninger bærer diagrammet. Den første er tolerance: om ændringen er lille nok til, at projektlederen kan godkende den under delegeret mandat, eller stor nok til at kræve styregruppen. Uden nedskrevne grænser når enten alting frem til styregruppen (hvilket gør den til en kø), eller også når intet frem, og ændringerne bliver lavet uformelt. Den anden er, hvad ændringsmyndigheden må svare. Godkend og afvis er ligetil; udsæt er det svar, de fleste registre håndterer dårligst, for en ændring, der er parkeret uden en genoptagelsesdato, kan ikke skelnes fra en, der blev ignoreret. Her har udsættelsen sin egen vej tilbage til et senere møde, og afvisning har en eksplicit lukket tilstand frem for tavshed.

Hvad dette flowchart dækker

I denne skabelon

• Fem swimlanes (Anmoder, Projektleder, Projektteam, Økonomi samt Ændringsmyndighed / styregruppe) fordelt på fem faser: Anmodning, Konsekvensvurdering, Godkendelse, Opdatering af baseline og Implementering og lukning.
• Modtagelsen i banerne Anmoder og Projektleder: opret en ændringsanmodning med beskrivelse og begrundelse, registrer ændringen i ændringsregistret, og derefter en gate, 'Er anmodningen klar nok til vurdering?', der sender tynde anmodninger tilbage til anmoderen for at tilføje detaljer og begrundelse, før de rammer den samme kontrol igen.
• Konsekvensvurderingen i banerne Projektteam og Økonomi: vurder konsekvensen for scope, tidsplan og kvalitet, estimer omkostning og vurder risiko, valider omkostning og finansieringskilde, og registrer så én samlet konsekvensvurdering (med muligheder, anbefaling og nul-løsningen) frem for en kommentartråd.
• Tolerancebeslutningen, 'Inden for projektlederens tolerance?', der leder Inden for til godkendelse under delegeret mandat og Overskrider til eskalering til styregruppen.
• Ændringsmyndighedens beslutning, 'Godkend, afvis eller udsæt?', med tre navngivne grene: Godkend videre til opdatering af baseline, Afvis til et lukket slutpunkt i anmoderens bane, og Udsæt til et bero-trin, der genoptager ændringen på et senere styregruppemøde.
• Fra opdatering af baseline til lukning: opdater projektets baseline, Økonomi opdaterer budget og omkostningsprognose, ændringen kommunikeres til interessenterne, projektteamet implementerer ændringen i planen, og leveringen bekræftes, før sagen lukkes.

Hvornår du skal bruge skabelonen

• I skriver afsnittet om ændringsstyring i en projektplan eller en PMO-håndbog og vil have vejen fra anmodning til opdateret baseline på én side.
• Ændringer bliver aftalt på møder og i chattråde, så ingen bagefter kan sige, hvad der blev godkendt, af hvem, og hvad det lagde til omkostningen og slutdatoen.
• I skal have det delegerede mandat på plads, før næste projekt starter: hvad projektlederen selv må absorbere, og hvad der skal til styregruppen.
• I overdrager et projekt til en ny projektleder eller introducerer en ny styregruppe og skal kunne vise, hvordan ændringer i scope, økonomi og tid bliver godkendt.
• En PMO eller et program standardiserer ændringsstyringen på tværs af projekter, der hver gør det på sin egen måde, før et ændringsregister sættes op i et projektværktøj.

Sådan fungerer det

1. Omdøb banerne, så de matcher jeres roller

   Erstat Anmoder, Projektleder, Projektteam, Økonomi og Ændringsmyndighed / styregruppe med de roller, I faktisk har. I et lille projekt kan ændringsmyndigheden være én sponsor, og Økonomi kan være en business partner, der ser tallene igennem på mail. Slå baner sammen frem for at tegne styringsorganer, der ikke findes, og hold antallet af baner på fem eller derunder, så diagrammet stadig kan læses.

2. Skriv jeres tolerancer ved siden af beslutningen

   'Inden for projektlederens tolerance?' er kun brugbar med tal bag. Notér den afvigelse i økonomi og tid, projektlederen må godkende, plus en regel for scope: for eksempel ingen ændring af aftalte leverancer, gevinster eller kontraktlige forpligtelser. Kører I PRINCE2, er det den tolerance, styregruppen delegerer, og den kan følges af et ændringsbudget, så rutineændringer aldrig når styregruppen. Aftal grænserne ved opstart, ikke første gang de bliver testet.

3. Definér, hvad konsekvensvurderingen skal indeholde

   Lav 'Registrer konsekvensvurderingen' om til en rigtig skabelon: virkning på scope, tidsplan, økonomi, kvalitet og risiko, finansieringskilden, de overvejede muligheder, en anbefaling og nul-løsningen. Sæt navn på, hvem der vurderer hver dimension, og hvor lang tid de får, for en vurdering, der tager tre uger, ender som en beslutning truffet uden den.

4. Sæt navn på ændringsmyndigheden og dens kadence

   Notér ved styregruppemødet, hvem godkenderne er, om der kræves beslutningsdygtighed, hvor ofte de mødes, og hvornår en sag skal være på dagsordenen. Beslut eksplicit, hvad der sker mellem møderne: enten må en navngiven person godkende akut og orientere på næste møde, eller også venter ændringen. Er dét udefineret, opstår de ændringer, der bliver godkendt på gangen.

5. Gør udsættelse tidsbestemt

   En udsat ændring skal have en genoptagelsesdato, en ejer og en aktiv status i registret, og derfor fører grenen Udsæt her tilbage til et senere styregruppemøde og ikke til et slutpunkt. Gennemgå de udsatte punkter på hvert møde, og luk dem, udviklingen har overhalet, med begrundelsen registreret, så registret afspejler beslutninger frem for at hobe dem op.

6. Fastlæg reglen for re-baselining, og udgiv derefter diagrammet med versionsstyring

   Skriv, hvilke godkendte ændringer der udløser en formel re-baseline, og hvilke der blot absorberes i prognosen, og kræv, at ændringens sagsnummer noteres på den nye baseline-version. Gem de tidligere baselines, så en afvigelse stadig kan forklares måneder senere. Del så diagrammet der, hvor arbejdet foregår (ved siden af ændringsblanketten og i projekthåndbogen), og hold styr på dets egen versionshistorik, så I kan vise, hvornår proceduren blev ændret, og hvorfor.

Ofte stillede spørgsmål

Hvad er forskellen på en projektændringsanmodning og it-ændringsstyring?

De svarer på hver sit spørgsmål. En projektændringsanmodning spørger, om en aftalt baseline (scope, økonomi, datoer og ofte gevinster) skal ændres, og beslutningen er kommerciel: hvad det koster, hvad det forsinker, hvem der finansierer det, og om business casen stadig holder. It-ændringsstyring spørger, om en ændring i en driftssat service må frigives, og beslutningen er operationel: risiko for brugerne, test, nedetidsvindue og rollback. Handler samtalen om CAB, ændringskalender og rollback-plan, så brug flowchartet for ændringsstyring (ITIL). Handler den om en styregruppe, en revideret slutdato og en budgetlinje, er det dette diagram, I skal bruge.

Hvad skal en ændringsanmodning i et projekt indeholde?

Nok til, at en anden kan vurdere den uden et møde: hvad der ændres og hvorfor, hvem der har rejst den og hvornår, hvad der udløste den (et nyt krav, en fejl, en ekstern afhængighed, en omgjort beslutning), hvor hastende den er, hvem der berøres, og hvad der sker, hvis intet ændres. Vurderingen tilføjer resten: virkning på scope, tidsplan, økonomi, kvalitet og risiko, finansieringskilden, de overvejede muligheder og en anbefaling. Hold de to som adskilte dokumenter. Anmodningen er anmoderens ord, og vurderingen er projektets svar, og slår man dem sammen, kan man bagefter ikke se, hvad der faktisk blev bedt om.

Hvem godkender en ændringsanmodning i et projekt?

Det afhænger af størrelsen, og det er præcis dét, tolerancebeslutningen i diagrammet er til for. Ændringer, der ligger inden for den afvigelse, projektlederen fik delegeret ved opstart, godkendes i banen Projektleder og registreres. Alt derudover går til ændringsmyndigheden, normalt styregruppen eller sponsoren. PRINCE2 beskriver ændringsmyndigheden som en rolle, styregruppen kan delegere, undertiden med et ændringsbudget, så rutineændringer ikke kræver en fuld styregruppebeslutning, og PMI's integrerede ændringsstyring bruger et change control board til det samme. Uanset hvad I kalder det, så skriv grænserne ned: en udefineret tolerance betyder, at enten eskaleres alt, eller også eskaleres intet.

Hvad betyder det egentlig at udsætte en ændring?

At beslutningen udskydes frem for at blive afvist, typisk fordi konsekvensen endnu ikke er klar, fordi ændringen afhænger af en anden beslutning, eller fordi den hører hjemme i en senere fase eller release. Det virker kun, hvis udsættelsen er tidsbestemt. I dette diagram fører grenen Udsæt til et bero-trin, der genoptager ændringen på et senere styregruppemøde og ikke til et slutpunkt, for en udsat ændring uden en vej tilbage er en afvisning, ingen har skullet begrunde. Giv hvert udsat punkt en genoptagelsesdato, en ejer og en synlig status i registret.

Skal man re-baseline efter hver godkendt ændring?

Re-baseline alt, der ændrer, hvad projektet har forpligtet sig til at levere, hvornår eller for hvor meget. Ellers måler afvigelsesrapporteringen mod en plan, I allerede har opgivet, og hver statusrapport kræver en mundtlig forklaring. Gem de tidligere baselines i stedet for at overskrive dem, notér ændringens sagsnummer på den nye version, og registrer godkendelsesdatoen. Små ændringer, der godkendes inden for tolerance, absorberes normalt i prognosen frem for at udløse en formel re-baseline: skriv i planen, hvad der er hvad, så to personer, der læser den samme rapport, når frem til det samme tal.

Hvordan forhindrer denne proces scope creep?

Ved at gøre prisen på en ændring synlig, før den aftales, i stedet for efter den er leveret. Scope creep er sjældent én stor beslutning; det er en række små tilføjelser, som et team absorberer uden nogensinde at sende dem til vurdering. De kontroller, der virker her, er registret, så hver anmodning har en sag; konsekvensvurderingen, så ingen godkender en tilføjelse uden at se, hvad den gør ved datoerne og budgettet; og tolerancegrænserne, så projektlederen ved præcis, hvor sit eget mandat stopper. Processen kan ikke forhindre ændringer, og skal ikke: den gør dem bevidste og sporbare.