Af en toe wordt mij gevraagd: "Waarom heb ik eigenlijk een projectmanager nodig voor mijn project? Kan ik niet gewoon rechtstreeks met de ontwikkelaar werken?"

Het antwoord is denk ik: kijk niet alleen naar de kosten die een project manager met zich mee brengt, maar eerder - wat zou het kosten als er geen projectmanager is..

Dit artikel gaat dus over verschillende soorten projectkosten.

1.      Tijd

De verschillende oplevermomenten die met elkaar zijn afgesproken moeten bewaakt worden. Een ontwikkelaar concentreert zich op de logica van uw applicatie, het schrijven van goede code en de technologische aspecten van de digitale interventie.

De ontwikkelaar is in mijn ogen wel verantwoordelijk voor het halen van de deadlines. Iedereen is altijd verantwoordelijk voor zijn eigen werk. De deadlines die de projectmanager of scrummaster in detail in een (sprint) planning zijn vastgelegd zijn dan leidend.

Door deze werkwijze kan de ontwikkelaar of designer gefocust blijven én toch verantwoording kunnen afleggen over zijn of haar werk en oplevermomenten.

Te laat opleveren is vaak een luxe die we ons niet kunnen permitteren en daarnaast geldt altijd, afspraak is afspraak.

2.      Scope

Uw project of applicatie moet een ‘definition of done’ hebben. Het moet voor de uw als opdrachtgever en als teamlid volkomen duidelijk zijn wat we gaan opleveren.

Stel dat er vanuit het projectteam of vanuit de kant van de opdrachtgever een verzoek komt, dat buiten de scope van het project valt of deel uitmaakt van een "wensenlijstje", kan een goede ontwikkelaar geneigd zijn om toch "ja" te zeggen. Daar herken je een goede ontwikkelaar aan.

We houden namelijk van mensen met een "yes we can" -houding, toch? Een ontwikkelaar denkt er waarschijnlijk over na hoe opwindend het is om dat nieuwe idee te kunnen implementeren (zonder rekening te houden met deadlines of budget).

Ik denk dat u als opdrachtgever, het eigenlijk helemaal niet zoveel uitmaakt of deze nieuwe functie er wel of niet in komt (liever wel natuurlijk). U bent eerder boos of teleurgesteld als een nieuwe functie wordt toegevoegd ten koste van de opleverdatum of zelfs budget.

Iemand in het projectteam, moet de voor- en nadelen kunnen bespreken van het toevoegen van een nieuwe functionaliteit. En namens u, er op wijzen dat de bovenliggende ambities en randvoorwaarden in balans moeten blijven.

3.      Budget

Uiteindelijk draait alles om geld. Is er voldoende tijd en geld; dan kan in feite alles gerealiseerd worden.  Maar de realiteit is weerbarstiger en budget is niet onbeperkt. Je hebt iemand nodig, die in de gaten kan houden hoeveel uren (en dus hoeveel euro’s) aan specifieke taken of Sprints worden besteed.

Een ontwikkelaar heeft eenvoudigweg niet de tijd, om deze belangrijke taak op zich te nemen. Het hoofddoel is gefocust te blijven op de code en een goed werkende applicatie op te leveren.

Wil een ontwikkelaar dan niet weten hoeveel uren er wekelijks worden verbrand? Nee, eigenlijk niet. Kan een ontwikkelaar de tijd nemen om dit soort rapportages op te stellen? Nee.

Je raadt het al – het liefst wordt alle tijd gebruikt om goede code te schrijven.

4.      Communicatie

Hoe meer tijd een ontwikkelaar doorbrengt in vergaderingen, e-mails schrijven, projectstatus bijhouden enz, hoe minder tijd hij of zij aan ontwikkeltijd kan besteden – en dus goede code schrijven. (Oké, ik val waarschijnlijk in herhaling?).

Daarnaast komt het zelden voor dat een ontwikkelaar ook een master is in communicatie; althans die kans is niet zo groot. Het is een zeldzame combinatie: mooie code schrijven en tegelijkertijd heel goed kunnen communiceren. Ja, en als iemand deze vaardigheden bezit, is het waarschijnlijk een architect of inderdaad, een projectmanager!

5.      Risicobeheer

Elk project heeft risico's. Plan risico's. Budgetrisico's. Kwaliteitsrisico's. Communicatierisico's. Iemand moet die risico's vroeg en op tijd identificeren en een strategie en oplossingsrichting bedenken en die vervolgens communiceren. Had ik al gezegd dat ontwikkelaars liever goede code schrijven?

6.      Documentatie

Documentatie is een belangrijk onderdeel van elk project en is in meerdere of mindere mate afhankelijk van het project zelf. Ontwikkelaars zijn ook verantwoordelijk voor het documenteren van de gekozen oplossing, zowel voor- als nadat de oplossing is gebouwd.

Iemand anders, namelijk de projectmanager, moet tijd besteden aan het documenteren van vergaderminuten, actie-items, projectplannen, enzovoort. Anders wordt uw ontwikkelaar opgezadeld met deze taak én dat is naar mijn idee echt niet de beste tijdbesteding van een  ontwikkelaar.

7.      Kwaliteitsborging

Al het werk wat wordt ontwikkeld, moet worden getest. Vanuit verschillende gebruikersrollen, wordt de applicatie onderhanden genomen, om te zorgen dat het project niet gaat mislukken.

Wat een veelvoorkomende fout is, is dat de ontwikkelaar zelf zijn werk gaat testen. U wilt uiteindelijk dat testers ook voldoende tijd en ruimte krijgen om het testwerkzaamheden goed uit te voeren. Daar wordt het project alleen maar beter van.

Misschien denk je na het lezen van dit artikel anders over project management. In plaats van je de vraag te stellen: "Waarom heb ik een projectmanager nodig voor mijn project? Kan ik niet gewoon rechtstreeks met uw ontwikkelaar werken?", is het beter om het wellicht zó te formuleren: "Wat zijn de kosten voor mij én mijn organisatie als het project later wordt opgeleverd, het budget is overschreden of de kwaliteit beneden pijl is? " Of nog erger: "Wat gebeurt er als het project mislukt?"