Hoe organiseer je de processen rondom een ontwikkelaanpak en rondom een SPOD? Natuurlijk is elk project anders en is de ideale organisatievorm situatieafhankelijk. (Zie ook Inrichtingsparameters.) Toch zien wij het volgende als basisonderdelen van een project- of programmaorganisatie:

 

• Multidisciplinaire ontwikkelteams, waarin mensen met alle benodigde expertises worden samengebracht, met voldoende mandaat.

• Een Design Office voor de centrale besturing van de SPOD. Anders gezegd: van de uitgangspunten en de resultaten, van de requirements en de ontwerpen t/m de eindresultaten.

1. Projectarchitectuur management

2. Requirements management

3. Configuration management

4. Change management

 

Het ligt voor de hand om deze processen hun eigen rollen (niet per se functies) te geven.

1. Projectarchitect

2. Requirements manager

3. Configuration manager

4. Change manager

 

Over de scope van een Design Office: te twisten valt over of requirements development en de integrale ontwikkelprocessen zelf ook onderdeel moeten zijn van dit Design Office. Het separaat organiseren geeft het Design Office een iets onafhankelijker status, waardoor het zijn faciliterende en meer bewakende rol (denk aan QA) beter kan vervullen.

 

Hoe groter het project, hoe meer requirements en design-producten. Het aantal verbanden tussen requirements onderling en tussen requirements en design-producten en tussen deze producten zelf, neemt exponentieel toe. Een gemiddeld project, zeker één met een IT-component, heeft al snel over de 1000 requirements. Gecombineerd met de dynamiek van wijzigingen op requirements en ontwerpen is het al snel onmogelijk om zonder specialistische expertise en tooling een project te doen met de zekerheid dat uiteindelijk opgeleverd wordt wat aanluit bij de behoefte en verwachtingen van de stakeholders.

 

De genoemde rollen zijn nodig, maar vanzelfsprekend kunnen –afhankelijk van de omvang – meerdere rollen gecombineerd worden in minder of meer personen.

 

Bij waterval en greenfield-aanpakken wordt de noodzaak voor requirements & design management door de meeste mensen onderschreven. Bij pakketimplementaties (COTS) lijkt de behoefte aan requirements minder sterk, maar dat is schijn.

IT-projecten die maatwerk maken zijn de processen leidend. (requirements van proces naar applicatie). Bij pakketimplementaties is de standaardfunctionaliteit van het pakket meer leidend, wil je gebruik maken van de efficiency-voordelen van een pakketoplossing. (requirements van applicatie naar proces).

 

Voor de samenstelling van de multidisciplinaire teams geldt dat bij pakketimplementaties het noodzakelijk is dat reeds in de ideefase voldoende expertise én mandaat van de leverancier wordt betrokken.

 

De ontwikkelaanpak is anders, maar het is nog steeds van het grootste belang de eigen requirements goed te administreren. Vooral afwijkingen van de standaardfunctionaliteit maar ook requirements vanuit het pakket richting de andere componenten zoals processen moeten worden bijgehouden. Zo kunnen die requirements extra testdekking en extra implementatie-aandacht krijgen.

 

Als Operational excellence leidend is, is het zaak hoog in te zetten op efficiency en dus de beheerbaarheid van de eindresultaten. Zo zullen de processen die ontwikkeld of aangepast worden in het project ´tot op het bot´ zijn uitgewerkt. Dit vraagt van een Design Office dat het zich ook verantwoordelijk zal moeten maken voor de details. Zeker in combinatie met een nieuwbouwproject is requirementsuitwerking op het diepste niveau noodzakelijk.

 

Is Product leadership leidend, dan staat vernieuwing voorop. Bij vernieuwende projecten zijn dan ook per definitie de business of product requirements leidend. Van een Design Office mag dan worden verwacht dat compliancy aan die business requirements management voorop staat. Afhankelijk van de andere parameters kan bij de inrichting van een Design Office worden overwogen om minder zwaar in te zetten op gedetailleerd requirements management.

 

Bij Customer intimacy stelt de organisatie zich in op het willen voldoen aan de specifieke behoeften van klanten. Dit vereist een hoge mate van flexibiliteit, niets zo veranderlijk als een klant. Voor een Design Office betekent dat dat het moet zijn voorbereid op het efficiënt omgaan met wijzigingen. En dus moet worden ingezet op soepel lopende change management en requirements management processen.

 

De mate van zekerheid over de stabiliteit van de requirements

In toenemende mate is wijzigende wet- en regelgeving de trigger voor projecten. Helaas zijn de wetgevende trajecten door politiek soms erg onvoorspelbaar en tegelijkertijd veeleisend. Het gebeurt niet zelden dat wetgeving nauwelijks rond is vóór de ingangsdatum en dat van organisaties wordt verwacht dat ze klaar staan voor de uitvoering. In dit soort projecten loont het om bij de inrichting van requirements management rekening te houden met mogelijke wijzigingen, bijvoorbeeld door een ´laag´ wettelijke requirements separaat te administreren en te traceren naar de onderliggende business requirements.

 

Al zijn de andere processen in een project ´houtje touwtje´ ingericht, dan nog is een Design Office nodig. Vanzelfsprekend moeten de investeringen wel in evenwicht zijn. Het heeft geen zin om uitstekend requirements management te hebben als het proces requirement development (analyse) te lage kwaliteit levert.

 

Een Design Office vraagt ook begrip van de stakeholders. Die worden bijvoorbeeld steeds eerder geconfronteerd met architectuur, met requirements en met lastige vragen. Zij zullen zich ook moeten conformeren aan een change management proces op ‘hun eigen’ requirements. Tegelijkertijd krijgen stakeholders vanuit een goed lopende Design Office veel meer inzicht in de projectresultaten in hun termen.

 

Om verschillende redenen kan de gewenste duurzaamheid van architecturen, ontwerpen en requirements hoog zijn, zoals de duur van het project of programma zelf of het hergebruik in andere projecten of programma´s. Dit webboek wijst op de grote kans op het gebied van integraal beheer van de projectresultaten in de ´verrichten´-laag. Van sommige producten ligt dat erg voor de hand. Zo wordt in de meeste organisaties wel functionele systeemdocumentatie in beheer genomen en onder change management gehouden. Dit gebeurt echter al veel minder vaak voor processen en de meeste andere kolommen van het raamwerk.

 

Terug naar het Design Office: als men nog lang van de projectresultaten gebruik zal maken, zal het Design Office nog meer dan normaal aan kennisborging moeten doen. Raadzaam is het dan om interne mensen vanaf het begin beschikbaar te maken ter voorbereiding op hun beheertaken in de verrichten-laag.

 

Hoe groter het verloop in een projectorganisatie, hoe groter de behoefte aan expliciete vastlegging van verwachtingen, afspraken en kennis. En dus zal in het Design Office de requirements & design-administratie grondiger worden ingericht.

 

In sommige projecten is er een grote behoefte aan creativiteit van de betrokkenen. Een gedegen administratie kan met een uitstraling van starheid creatieve processen frustreren. Bij het inrichten van een Design Office in een dergelijke situatie dient rekening te worden gehouden met een soepel lopend change proces. Communicatieve vaardigheden, ruimdenkendheid en flexibiliteit zijn requirements aan de bezetting van het Design Office.