2 – Prepare

Indien U samen met ons aan het project begint, bepalen we gezamenlijk de missie, de hoofddoelstellingen, de gewenste tussenresultaten en eindresultaat van het project.

Ieder project begint daarom met een chartering sessie. Dit is veel meer dan een standaard kick-off meeting met een praatje van de executive en een gezamenlijk etentje of andere activiteit om elkaar te leren kennen. Een chartering is “hard work”. Doel van een chartering sessie is om het project een goede start (richting) te geven en commitment van alle deelnemers te verkrijgen. Hierbij komen de volgende onderwerpen aan bod:

• Visie, missie statement, (hoofd)doelstellingen van het project
• Business case
• Scope
• Belangrijke constraints en aannames
• Succesfactoren
• Project community (deelnemers, met welk commitment, in welke rol, verantwoordelijkheden, bevoegdheden)
• Afspraken over aanpak, samenwerking, communicatie (intern en extern)
• Initiële product backlog
• Initiële project roadmap (of release plan)

Een goede chartering sessie zal vaak meerdere dagdelen in beslag nemen. De deelnemers bestaan uit de sponsor, de beslissingsbevoegden van de stakeholders (in termen van Prince2: executive, senior user, senior supplier) en alle uitvoerende projectleden. Het zijn immers de projectleden die het project tot een succes moeten maken! Het meest kritische aan de chartering is het proces zelf. Persoonlijke vetes, big ego’s, “politiek” en dubbele agenda’s kunnen zeer frustrerend werken. We stellen dan ook hoge eisen aan de facilitator van de chartering sessie.

De formulering van een goed missie statement en heldere project doelstellingen wordt vaak onderschat. Gedurende een project worden allerlei beslissingen op allerlei niveaus genomen. Bij een goed missie statement en heldere project doelstellingen zijn alle te nemen detailbeslissingen door gebruikers, ontwikkelaars en testers veel gemakkelijker te toetsen op de toegevoegde waarde aan het project (business value).  Daarnaast zijn een goed missiestatement en heldere projectdoelstellingen een zeer belangrijke “motivator” voor de projectleden: iets waarmee de projectleden zich kunnen identificeren, iets waar ze het voor (willen) doen.

De product backlog bestaat uit alle functionaliteit (in de vorm van user stories) en non-functional requirements (in de vorm van constraints), die door de ontwikkelaars moeten worden opgeleverd, door de testers getest en door de gebruikers geaccepteerd.

Nadat de product backlog is gecompleteerd, de user stories en constraints zijn geschat op benodigde capaciteit, kunt U als gebruiker de user stories en constraints gaan prioriteren. Hierbij zal business value tegen de kosten worden afgewogen: een minder waardevolle user story kan de voorkeur krijgen boven een user story met meer waarde als de eerste veel ‘goedkoper’ is. De capaciteit van het ontwikkel- en testteam bepaalt vervolgens hoeveel “story points” per iteratie kunnen worden opgeleverd. Daarna kunnen op basis van de prioriteit, kosten en beschikbare capaciteit de user stories en constraints over de iteraties worden verdeeld. Dit noemen we de project roadmap of release plan.

1 – Align

2 – Prepare

3 – Deliver

4 – Use