Tagcloud

Projectinitiatie kan óók agile!

Herken je deze situatie? Business mensen zijn vol lof over agile. Pragtische aanpak, makkelijk omgaan met verandering, verkorte ´time-to-market´, sterke focus op doelstellingen en vooral een goede ´alignment´ tussen business en IT. Mooie woorden, maar bij alignment denkt de ‘business’ aan de operationele kant van het project. In praktijk worden daarom veel projecten op een klassieke, vaak tijdrovende manier geïnitieerd, om vervolgens pas daarna agile vorm te krijgen. En dat terwijl we snel op zoek zijn naar de klassieke go/no-go-beslissing!

Eigenlijk is het helemaal niet zo vreemd, want de meeste agile methoden reppen geen woord over hoe ook het voortraject pragmatisch vorm gegeven kan worden. Als er iets is wat een agile aanpak probeert bewust te maken, is dat we niet op zoek moeten gaan naar regeltjes. Het zijn de onderliggende principes die we ons eigen moeten maken. Een van die principes is dat mondelinge communicatie het meest effectief is voor het overdragen van informatie. Gek genoeg denken we hierbij niet gedacht aan projectinitiatie! Niet dat we nu alles achterop een bierviltje moeten schrijven, genietend van een goed glas wijn op de golfbaan. We hebben immers toch iéts nodig wat we kunnen opschrijven om tot overeenstemmening te komen. En bij de daadwerkelijke uitvoer van een agile project is een gemeenschappelijk beeld creëren des te belangrijker. Het zijn immers de businessdoelstellingen en een heldere visie die we hard nodig hebben om op koers te blijven in een projectomgeving waar verandering onvermijdelijk is.

De ‘pre project fase’ kennen we in Engelse literatuur als project chartering, project inception of simpelweg project initiation. Mooie kreten met hetzelfde doel;  helder krijgen waarom we het project doen, wat er voor nodig is en hoe we het gaan aanpakken. In een traditionele aanpak ontstaan vaak ceremoniële documenten, die zich stroperig door de organisatie bewegen en voor de nodige ambiguïteit te zorgen. Bovendien dragen deze, vaak lijvige documenten bij aan de illusie dat we een project voorafgaand in één keer te kunnen bedenken en vastleggen.

We denken dat er consensus is, terwijl die er niet is. En ja, natuurlijk hebben een aanpak die met verandering om kan gaan, zodra we daar achter komen. Maar is het niet beter het paard weer voor de wagen te plaatsen? Waar het om gaat is dat we de essentie van het project, op een strategisch detailniveau in kaart brengen en deze op een eenduidige manier communiceren. Maar hoe doen we dat? Jonathan Rasmusson beschrijft in zijn boek ‘The agile samurai’ een aardige aanpak, die invulling geeft aan deze vraag.

De kracht van zijn aanpak is om in een kort tijdsbestek te streven naar helderheid, iedereen op dezelfde golflengte te krijgen, de juiste verwachtingen te scheppen en de basis te leggen voor een go/no-go-beslissing. In het kort; zet de juiste mensen bij elkaar in een ruimte en laat ze via een aantal vragen, opdrachten en een handvol afbeeldingen en schetsen de  essentie van het project destilleren. Hiermee wordt een gemeenschappelijk beeld gecreëerd van de omvang, complexiteit en scope van het project. De samenstelling van deze groep is daarbij van belang. Het is namelijk niet alleen een aanpak voor de leverancier, maar ook voor de opdrachtgever om hulp te bieden bij de kritische go/no-go beslissing.  Hoe je deze groep kunt identificeren en samenstellen zal ik in een andere blog toelichten.

De workshop richt zich op de volgende 10 vragen en oefeningen. 

1. Waarom we hier zijn?
Waarom zijn we hier, wie zijn onze klanten en waarom hebben we besloten dit project te doen?

Je weet pas hoe je een goed product maakt, als je weet waarom het gemaakt moet worden. Wat is het probleem of wat de ‘opportunity’ is? Wat wil je bereiken? Efficiëntie?  Kostenreductie? Productinnovatie? Omzetverhoging? Zo maar enkele doelstellingen die essentieel zijn het maken van afwegingen tijdens het project.

2. Maak een elevator pitch.
Als we dertig seconden de tijd zouden hadden om het project te beschrijven, wat zouden we dan zeggen?  Een goede ‘elevator pitch’ helpt je hierbij. Het beschrijft wat het product is, voor wie het is en wat de belangrijkste eigenschappen zijn die het speciaal maakt. Er is een handige template die je dwingt je te beperken tot de essentie.

3. Ontwerp een verpakking.
Wat zijn de belangrijkste redenen waarom mensen het product willen kopen of gebruiken? Met welke slogan zou je het product het beste kunnen omschrijven? De kunst is een project altijd te beschouwen als een product. Een product met eigenschappen, waar behoefte aan is. Een bekende agile oefening is om het team een reclameverpakking te laten ontwerpen. Het is niet een direct pleidooi je kleuterschoolperiode te laten herleven; ook zonder kleurpotloden kom je tot de essentie van deze opdracht. Wat zet jij op de voorkant en welke typische eigenschappen op de achterzijde om het aantrekkelijk te maken om te kopen?

4. Maak een NIET lijst.
Bij de start van elk nieuw project hebben betrokkenen vaak een andere perceptie van project succes. Helaas komen we daar bij de daadwerkelijke uitvoer van een project pas achter. Een lijst in kaart brengen wat in scope is en ook vooral wat niet in scope draagt bij aan gezamenlijke verwachtingen.  Een project starten zonder deze overeenstemming is gedoemd te falen. Alhoewel in deze face niet een strikte must, helpt het user story formaat ons de focus te leggen op waarom we het in de  scope opnemen.

5. Ontmoet de context van je project.
Met welke mensen in de organisatie moet je een relatie op bouwen om een succes te maken van je project? Meestal focussen we ons op het kernteam, maar vaak is er een bredere blik in de organiatie nodig om het project succesvol te maken. Het zorgt er voor dat de je een beroep op ze kunt doen als je ze nodig hebt.

6. Toon de oplossing.
Schets een high level blauwprint van de architectuur om er zeker van te zijn dat we allemaal hetzelfde denken. Het streven is een beeld krijgen van de complexiteit, architectuur en benodigde technologieën nodig om het systeem te maken. Doel is om technische issues in een vroeg stadium boven tafel te krijgen. Als je er op rekent dit project aan te pakken met bepaalde tools of een specifieke architectuur, dan is het beter dit zo vroeg mogelijk te vermelden. Je wilt namelijk niet te laat worden verrast met standaarden en richtlijnen van de klant. Die schets hoeft op voorhand niet volledig te zijn, maar laat dit dan wel weten!

7. Vraag wat ons ’s nachts wakker houdt.
Veel betrokkenen zijn niet bewust van de inherente risico’s en problemen die gepaard gaan met software projecten. De voornaamste risico’s vooraf in kaart brengen en hoe er op gereageerd kan worden zodra ze zich voordoen is iets wat je beter voorafgaand in kaart wil brengen, dan op het moment dat het probleem zich voordoet.

8. Wat is de initiële omvang?
We kunnen voorafgaand onmogelijk weten  hoeveel mandagen een project exact gaat duren. Wel kunnen we bepalen wat de eerste omvang van het project is. Is het een project van drie, zes of negen maanden?

9. Wees duidelijk over wat er gaat meegeven.
Elk project heeft concurrerende en soms zelfs tegengestelde wensen. Klanten willen dat alles gisteren af is, dat het budget niet overschreden wordt en dat de exacte scope in de hoogste kwaliteit wordt opgeleverd. In deze veranderlijke wereld is dat onmogelijk. Beter om in dit stadium van het project dan de wensen te prioriteren.

10. Wat hebben we nodig?
Hoeveel gaat het kosten? En wat voor team hebben we nodig om dit van de grond te krijgen?

Faciliteer deze workshop met bijvoorbeeld een presentatie. Mocht je vragen hebben over deze aanpak en hoe je deze faciliteert, neem dan gerust vrijblijvend contact op!

  
Problem to solution