Stage-Gate (Waterval methode)


Stagegating is een projectmanagementtechniek die ervoor zorgt dat een project wordt verdeeld in duidelijke fasen en het besluit om met een volgende fase te starten niet te licht wordt genomen. De verschillende hoofdfasen (stages) en procesfasen (phases) worden bij de projectstart vastgelegd en afgesloten met ‘poorten’ (gates). De poort wordt pas geopend als aan vooraf gedefinieerde eisen is voldaan.

Het idee om een project in fasen te verdelen en de overgangen te bewaken is ontstaan in de maakindustrie en overgenomen door de ICT-sector waar het bekend is geworden als de waterval methode. De vergelijking met een waterval illustreert goed hoe de methode in de praktijk werkt: water stroomt tot het volgende obstakel en kan pas verder als dat wordt weggenomen of het water er overheen stroomt. Bij projecten is er vaak een grote druk om een volgende fase te starten, ondanks dat er eigenlijk nog niet helemaal aan de voorwaarden is voldaan: medewerkers moeten bezig blijven, deadlines gehaald ed. Mits het besluit om het obstakel te passeren weloverwogen en door bevoegde managers worden genomen hoeft dit geen probleem te zijn.

Fasen
Verschillende projectmanagementmethoden schrijven vaste stagegates voor. Veel organisaties hanteren hun eigen methode met stagegates die zijn aangepast aan de eigen projecten. Als het voor de projectbeheersing nodig is, mogen bovendien vaak extra gates worden toegevoegd. Afhankelijk het soort project, de mate waarin het beheerst moet worden en hoe een organisatie met Stagegates wil omgaan, kunnen deze dus per project verschillen. Standaard worden meestal vijf fasen en bijbehorende Stagegates onderscheiden:

  1. Afbakenen van de scope: waar gaat het project precies over?
  2. Ontwikkelen van de Business Case: wat is de legitimatie van het project? Waarom is het project de investering in tijd en middelen waard?
  3. Ontwerpen en produceren projectresultaat: wat gaan we precies ontwikkelen? Aan welke eisen gaan we voldoen?
  4. Testen en valideren: Voldoet datgene wat we hebben ontwikkeld aan de eisen en werkt het naar behoren?
  5. Lancering: Zijn we klaar om het projectresultaat te gaan verkopen/in gebruik te nemen.

Vaak worden de fasen onderverdeeld in deelfasen met extra stagegates. In het voorbeeld hierboven, vormen het ontwerpen van het product en maken van het prototype bijvoorbeeld een enkele fase, die wordt afgesloten met een stagegate. Het kan verstandig zijn pas te beginnen met het bouwen van een (duur) prototype, nadat eerst het detailontwerp is goedgekeurd. Ook na Fase 5 kunnen extra stagegates nuttig zijn, bijvoorbeeld om te garanderen dat de verkoopcampagne pas start wanneer het product daadwerkelijk beschikbaar is en alle marketingmateriaal gereed, getest en goedgekeurd is.
Bij wat complexere projecten, kunnen er allerlei andere stagegates voorkomen, zoals het goedkeuren van de ontwerpoplossingen (basisontwerp), beoordelen of het ontwerp voldoende is uitgewerkt om te gaan bouwen (detailontwerp), beoordeling van het prototype, beoordeling van het productieproces, beoordeling veldtest (voor productlancering) en beoordeling nul-serie (na lancering).

Starten van een Stage review
De projectmanager en -team bepalen meestal samen of een project klaar is voor de volgende fase. Zo ja, dan vraag de projectmanager de review aan. Hierdoor start het reviewproces, waarbij inhoudelijk deskundigen en beslissers samen – al dan niet in meerdere reviewrondes – het project beoordelen. Projectmanager, teamleden, inhoudelijk deskundigen, opdrachtgever en/of vooraf bepaalde bevoegde organen (bv. Stuurgroep en Governance Board) en individuen beoordelen het project op allerlei aspecten, waaronder:

  • De Business Case: kloppen de uitgangspunten nog (de legitimering van het project)? Is het nog verantwoord het project door te zetten?
  • De vorderingen en gebruik van resources. In hoeverre wijkt de uitvoering af van het projectplan en is dit acceptabel?
  • Is het tijdspad nog realistisch en zo nee, is het nodig en mogelijk dit bij te sturen, bijvoorbeeld door extra resources ter beschikking te stellen?
  • Resultaten. Is wat opgeleverd is van voldoende kwaliteit? Is het ontwerp bijvoorbeeld voldoende uitgewerkt om te gaan investeren in een prototype of productielijn?
  • Zijn er openstaande issues (ontwerpwijzigingen, ideeën, problemen), die moeten worden opgelost voordat de volgende fase mag starten.
  • Wat zijn de risico’s? Zijn deze beheersbaar en acceptabel?

Soorten projectreviews

Door stagegates te formaliseren, wordt gegarandeerd dat besluiten worden genomen door de juiste beslissers op basis van de juiste criteria. Dit gebeurt tijdens reviews, waarin inhoudelijk deskundigen en besluitvormers op basis van vooraf vastgelegde criteria het project beoordelen en samen evalueren of het al verantwoord is om verder te gaan. Afhankelijk van de complexiteit, kan zo’n review variëren van een eenvoudige bespreking van het projectteam met de opdrachtgever, tot een keten van reviews, waarbij allerlei organen en teams zijn betrokken, voordat een onderbouwd besluit kan worden genomen om de volgende projectfase te starten.
Reviews hebben betrekking op verschillende aspecten (bv. techniek, klantervaringen, projectresources). Er worden dan ook verschillende soorten reviews onderscheiden. Enkele voorbeelden:

  1. Ontwerp review: voldoet het ontwerp aan de eisen? Dekt het alle interne en externe eisen en wensen af?
  2. Gebruikersreview: vinden (test)gebruikers het (voorlopige) projectresultaat bruikbaar? Zijn er verbeteringen nodig om het (beter) te laten functioneren of gebruiksvriendelijker te maken.
  3. Projectreview: ligt het project op koers (resultaten, tijd, geld en andere middelen) en zijn de risico’s voldoende onder controle?
  4. Gate review: wordt aan alle voorwaarden voldaan om de volgende fase te starten (zijn alle voorgaande reviews akkoord). En zo nee, kan dit onder voorwaarden plaatsvinden; bijvoorbeeld onder de voorwaarde dat openstaande issues binnen een bepaalde tijd zijn opgelost?

Bovendien en er moeten vaak besluiten op verschillende niveaus worden genomen. De samenstelling van de multidisciplinaire reviewteams verschillen dan ook per review. Het besluit dat het ontwerp aan de eisen voldoet, zal bijvoorbeeld vaak worden genomen door een engineering manager in overleg met een vertegenwoordiger van de klant, terwijl de uiteindelijke Gate Review door het topmanagement en/of de Stuurgroep wordt genomen.

Stagegate Checklist
Om te garanderen dat besluiten door de juiste mensen en op basis van de juiste criteria worden genomen, legt men beoordelingseisen vooraf vast in checklists. Deze checklists moeten voor ze gebruikt mogen worden, zijn goedgekeurd. Vaak vormen deze een bijlage bij het projectplan, maar het is ook mogelijk de checklists tijdens het project tot stand te laten komen, mits bevoegde managers de inhoud accorderen. In zo’n checklist staat per Stagegate uitgewerkt:

  • Op welke aspecten de fase wordt beoordeeld (dit verschilt per fase)
  • Welke criteria hierbij gelden en doe deze moeten worden gemeten
  • Aan welke normen de criteria moeten voldoen
  • Wie bij de verschillende boordelingen moeten worden betrokken
  • Wie de verschillende onderdelen van de checklist mogen tekenen voor akkoord. Meestal tekenen er andere managers voor de verschillende beoordelingen.
  • Wie tekent voor decharge en het starten van de volgende projectfase.

Mogelijke resultaten van een Stage Review
Er zijn verschillende beoordelingen mogelijk:

  • Akkoord: het project voldoet aan alle voorwaarden en de volgende projectfase kan worden gestart
  • Akkoord, on hold: het project voldoet aan de voorwaarden, maar wordt tijdelijk stilgezet. Bijvoorbeeld omdat een ander project een hogere prioriteit heeft, of er tijdelijk onvoldoende middelen ter beschikking zijn.
  • Akkoord onder voorwaarden: er is niet aan alle eisen voldaan, maar er mag toch worden verder gewerkt. Dit kan gebeuren als de beoordelaars van menig zijn dat er niet kan worden gewacht en de risico’s bij doorwerken aanvaardbaar zijn. De issues en voorwaarden waaronder de volgende fase worden meestal expliciet op de checklist benoemd, voordat deze wordt getekend.
  • Niet akkoord: het project mag niet verder, voordat het aan de voorwaarden voldoet
  • Project stopt: de Business Case in niet langer valide. Verder werken is niet aanvaardbaar, bijvoorbeeld omdat verdere inspanningen het resultaat niet rechtvaardigen, of omdat het risico dat het resultaat niet wordt gehaald te groot is geworden.