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

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.