Reading time: 7 minutes
Author:
Complexiteit en onzekerheid hebben grote invloed op de systeem- en softwareontwikkeling. Hans Sassenburg van het Software Engineering Institute (SEI), het orgaan achter onder meer het Capability Maturity Model (CMM), analyseert een viertal projectmanagementvarianten die voortvloeien uit het samenspel van complexiteit en onzekerheid. Hij gaat in op de kenmerken, zoals de benodigde kwalificaties van de projectmanager. Ook geeft hij voorbeelden van toepassingsomgevingen.
Net als bij koken, zou er in projectmanagement een variëteit aan bereidingswijzen moeten zijn. Voor het bakken van eitjes voor je gezin hoef je minder oplettend te werk te gaan dan voor het bereiden van een luxe maaltijd voor een sjiek gezelschap. De ene maaltijd vergt een ander soort kok dan de andere. Een patatbakker in een viersterrenrestaurant is geen garantie voor succes. Omgekeerd zal een topkok zijn neus ophalen voor het bakken van een frikadelletje.
Er is de laatste decennia nogal wat gediscussieerd over projectmanagement. Bekende aanpakken als Prince2, PMBOK, life-cyclemodellen en kwaliteitsstandaarden vochten om aandacht. Op kwaliteitsgebied is de discussie overigens wat uitgekristalliseerd. ISO 9000:2000 is te abstract voor systeemontwikkeling. Om verbeteringen in projectmanagement te stroomlijnen kiezen bedrijven veelal voor CMM en de opvolger CMMI. Toch lijdt dit soort discussies onder een gezamenlijk probleem. Het is óf het een óf het ander (zie Figuur 1). Dat is op z‘n zachtst gezegd opmerkelijk.
Standaard versus op maat
Hoge onvoorspelbaarheid speelt nog altijd een grote rol bij systeem- en softwareontwikkeling. De jaarlijkse rapportages van de Standish Group spreken voor zich. Deze projecten kampen met late leveringen, budgetoverschrijdingen en producten die niet altijd aan klantwensen voldoen. De gepubliceerde resultaten over 2003 laten zelfs zien dat de situatie eerder verslechtert dan verbetert.
Dit is verklaarbaar. Managers krijgen wellicht een betere grip op het ontwikkelproces, maar desondanks neemt de complexiteit en onzekerheid in projecten toe. Systemen worden systemen-van-subsystemen, veelal door verschillende leveranciers ontwikkeld. Grote OEM‘s zoals in de automotive-industrie zijn systeemintegratoren. Zelf ontwikkelen ze nauwelijks nog. De systemen kampen met de complexe coördinatie van zelfstandig opererende subsystemen. Meer subsystemen leidt tot een combinatorische explosie van mogelijke (fout)situaties.
Verder snelt de technologie voort, zodat elk nieuw product flinke technologiewijzigingen kent of zelfs een generatiebreuk betekent ten opzichte van eerdere producten. Dit vormt een grote bron van onzekerheid. De aanname is dat de aanwezigheid van complexiteit en onzekerheid pleit voor een specifieke projectmanagementaanpak.
Ik formuleer de volgende hypothese: Projectmanagement op maat verhoogt de slagingskans van projecten.
Deze stelling is uit te werken in een drietal afgeleide regels. Systeemontwikkelaars zijn zich ongetwijfeld bewust van complexiteit en onzekerheid. Echter, in de praktijk trachten ze veelal verschillende projectentypen met dezelfde werkwijze aan te pakken. Hun manier van werken is vastgelegd in het kwaliteitssysteem en elk project dient zich te conformeren aan de geldende regels. Of het nu de vervolgontwikkeling is van een stabiel product of de eerste productontwikkeling van een technologische innovatie. Dit is een starre houding die vermeden moet worden en leidt tot de eerste regel:
Een specifiek projecttype vereist een specifieke projectmanagementaanpak.
Maar niet alleen de aanpak dient op maat te zijn. Ook het profiel van de projectmanager moet waarschijnlijk aan specifieke eisen voldoen. Dit is de tweede regel:
Een specifiek projecttype stelt specifieke eisen aan het profiel van de projectmanager.
Ten slotte speelt ook de informatie voor het monitoren van de status en voortgang van een project een belangrijke rol. De aanname is dat deze informatie ook per projecttype zal verschillen. Dit leidt tot de derde regel:
Een specifiek projecttype stelt specifieke eisen aan de benodigde managementinformatie.
Leuk die hypothese met drie afgeleide regels, maar wat moet je ermee? Laten we het wat meer handen en voeten geven. In Figuur 2 zijn de dimensies onzekerheid en complexiteit uit elkaar getrokken en op elkaar afgebeeld. Dit levert vier kwadranten met vier specifieke projectmanagementvarianten. Deze vier varianten – behoudend, degelijk, flexibel en dynamisch – komen elk kort aan de orde:
Behoudend
Deze variant nodigt juist wel uit tot toepassing van de normale projectmanagementaanpak. Een specifieke maatbenadering is niet vereist vanwege de lage complexiteit en lage onzekerheid. Het nodigt zelfs uit tot het klassieke watervalmodel met een stapsgewijze strategie, omdat de specificaties naar verwachting bekend zijn. Prince2 lijkt een geëigende projectmanagementmethode.
De projectmanager hoeft geen jarenlange ervaring te hebben en mag zelfs in opleiding zijn. Hij kan het vak leren met het doorlopen van dit soort standaardtrajecten. Voorwaarde is dan wel dat er coaching is door een meer ervaren projectmanager.
De bewaking van de status en voortgang van dit type project is duidelijk. Een goed uitgewerkt managementplan inclusief planning vormt de basis. De voortgangsrapportages naar het management zullen zich beperken tot het aangeven in hoeverre geraamd budget en planning zich verhouden tot de realiteit. Recht toe, recht aan.
Dit type projecten komen we vaak tegen in de praktijk. Een goed voorbeeld is het voortborduren op een bestaand product met vervolgreleases zonder grote innovaties.
Degelijk
Toenemende complexiteit vergt een andere benadering. Hoewel de standaard werkwijze nog toepasbaar kan zijn, komt de nadruk te liggen op het reduceren van de complexiteit. Een goede architectuur is hier van wezenlijk belang, zodat subsystemen met een duidelijk gespecificeerd gedrag kunnen worden overgedragen of uitbesteed voor implementatie.
De projectmanager zal iemand moeten zijn die een goed overzicht behoudt over zowel de architectuur (technisch inhoudelijk) als de correcte implementatie ervan door verschillende teams en leveranciers (afstemming). Conceptueel denken en ervaring zijn vereisten. Eventueel kan hij of zij hierbij steun krijgen van een technisch specialist of een verantwoordelijke voor de coördinatie tussen alle betrokken partijen.
De voortgangsrapportages naar het management zullen zich niet alleen maar richten op de voortgang ten opzichte van de ramingen. Ook moet duidelijk zijn of de gekozen oplossing inderdaad het complexe probleem oplost. Tussentijdse verificaties zijn daarbij onontbeerlijk. Dus niet alleen testen tegen het moment van integratie van de verschillende subsystemen, maar rigoureuze inspecties van elk subsysteem tijdens de implementatie zelf. Een standaard werkwijze gebaseerd op de watervalaanpak kan hier wellicht gehandhaafd blijven, op voorwaarde dat de specificaties redelijk bekend en stabiel zijn. Architectuur en verificaties verdienen wellicht meer expliciete aandacht.
Dit type projecten komen we ook vaak tegen in de praktijk. Een goed voorbeeld is het ontwikkelen van een complex navigatiesysteem. Betrouwbare, maar tevens geoptimaliseerde algoritmes spelen hier een grote rol.
Flexibel
Toenemende onzekerheid vergt weer een andere benadering. Nu ligt de nadruk niet op het reduceren van complexiteit, maar op het reduceren van onzekerheden. Hierbij is het van belang om de verschillende opties zolang mogelijk open te houden. Besluiten over architectuur of technologie moeten zolang mogelijk worden uitgesteld. Ook moeten managers er niet voor schromen om eerdere keuzes terug te draaien, indien hier aanleiding toe is. Een standaard werkwijze laat dit veelal niet toe. Het is onrealistisch om te eisen dat onderdelen op mijlpalen definitief zijn afgerond. Dit is een te starre benadering voor dit type projecten. Iteratieve aanpakken als DSDM of Scrum zijn mogelijke alternatieven voor de op de waterval gebaseerde werkwijze.
De projectmanager moet tegen de onzekerheid opgewassen zijn. Niet iedereen is dat. Senioriteit is ook hier belangrijk. De voortgangsrapportages naar het management
zijn ook nu niet alleen tot tijd en geld beperkt. Een langetermijnplanning zal moeilijk te maken zijn. Veel belangijker is het continu in kaart brengen welke richtingen het project op zou kunnen gaan: welke opties zijn nog open met welke implicaties?
Een voorbeeld uit de praktijk is de ontwikkeling van een nieuw consumentenproduct, zoals een nieuwe MP3-speler. De complexiteit is niet het probleem, maar de technische keuzes.
Dynamisch
Ten slotte de moeilijkste en meest interessante variant. Zowel complexiteit als onzekerheid zijn in hoge mate aanwezig. Het is schipperen tussen een goede architectuur om de complexiteit te reduceren en het zolang mogelijk openhouden van verschillende opties. Slapeloze nachten? Creativiteit en innovatie staan hier hoog in het vaandel en dit zal ook specifieke projectmedewerkers aantrekken. Meestal mensen die langere tijd onder hoge spanning geconcentreerd kunnen werken om het product ondanks alle tegenslagen toch te realiseren.
Maar niet tegen elke prijs. Het zal ook een betrouwbaar en onderhoudbaar product moeten zijn. Dit vereist een door de wol geverfde projectmanager die met dit soort situaties goed om kan gaan. Enerzijds moet hij of zij te allen tijde naar binnen en buiten richting kunnen blijven geven. Een opmerking als ’ik weet het zelf ook niet meer‘ is dodelijk voor de motivatie en het vertrouwen van de andere projectleden. Anderzijds zal hij of zij de ruimte moeten geven voor creativiteit en innovatie. Dit type project betreft meestal niet alleen ontwikkeling pur sang maar kent ook een onderzoekscomponent. Een standaard werkwijze zou de creativiteit en innovatie kunnen belemmeren. Toepassing op hoofdlijnen is mogelijk, zolang het helpt transparantie te bieden. Pas als de echte productontwikkeling start is een rigoureuzere toepassing te overwegen.
Rapportages naar het management adresseren zowel het product zelf (hoofdlijnen architectuur) als de openstaande technologiekeuzes (opties).
Voorbeelden van dit soort projecten komen we vaak tegen in de embedded-softwarewereld. Hier is de grens tussen ontwikkeling en onderzoek niet altijd zo strikt. Vaak betreft het de ontwikkeling van een nieuwe generatie systemen, zoals een waferstepper, medisch apparaat of geavanceerde printer.
De vier besproken varianten komen voort uit de gekozen dimensies complexiteit en onzekerheid. Dit is geen zwart-witopdeling. Natuurlijk zijn er projecten denkbaar die zich op de raakvlakken bevinden. Daardoor zijn ze te karakteriseren door de kenmerken van twee of zelfs meer varianten.
Bent u het niet eens met de gekozen dimensies, karakteristieken of profielen? Geen punt, de toepassing is aan u. Zolang u voor de start van een project maar bewust nadenkt over het profiel van de projectmanager en in hoeverre afgeweken mag worden van vastgelegde (vastgeroeste?) werkwijzen. Voer voor uzelf de volgende exercitie uit. Zijn ’mislukte‘ projecten uit het verleden te verklaren aan de hand van de drie stellingen en het conceptuele model? Zo ja, dan heeft u een instrument voor de toekomst. Zo nee, laat het me weten.
Hans Sassenburg (hanss@sei.cmu.edu) is zelfstandig adviseur en werkzaam bij Software Engineering Institute Europe, het orgaan achter onder meer CMMI.
