Waarom wij geen projectmanagers hebben

# Waarom wij geen projectmanagers hebben — en waarom dat jou meer oplevert

Elke euro die je betaalt aan een projectmanager, betaal je voor iemand die jouw woorden omzet naar andermans woorden.

Dat klinkt hard. Maar het is precies wat er gebeurt bij de meeste bureaus. Jij legt een wens uit aan een accountmanager. Die schrijft een briefing voor een projectmanager. Die maakt een ticket in Jira. Een developer leest dat ticket, stelt een vraag, de projectmanager stuurt die door, jij antwoordt, de projectmanager vertaalt het antwoord, de developer bouwt — hopelijk — wat jij bedoelde.

Dit is het standaard bureau-model. En het is kapot.

Wat er misgaat in het klassieke bureau-model

Bureaus zijn gebouwd op schaalbaarheid. Ze willen twintig klanten tegelijk bedienen met een team van developers die zo veel mogelijk uitwisselbaar zijn. De projectmanager is de lijm die dat systeem bij elkaar houdt.

Dat klinkt efficiënt. In de praktijk is het een machine voor het produceren van misverstanden.

Het informatieverlies is structureel. Elke keer dat een boodschap wordt doorgegeven, verdwijnt er context. Niet omdat mensen niet hun best doen, maar omdat het onmogelijk is om de nuances van een gesprek volledig over te dragen in een ticket of een samenvatting. De subtiele "eigenlijk willen we dit liever flexibel houden" wordt een harde requirement. De twijfel die je uitsprak over een schaalbaarheidskeuze verdwijnt in de marge.

Prioriteiten raken zoek. Een projectmanager beheert meerdere projecten tegelijk. Jouw urgentie is voor hem één van de vijf urgente zaken van die dag. Dat betekent vertraging op momenten waarop snelheid juist cruciaal is — een bug vlak voor Black Friday, een feature die de concurrent al heeft.

Verantwoordelijkheid wordt diffuus. Als iets mis gaat, is de vraag altijd: wie heeft dit gecommuniceerd? Was het de briefing? Het ticket? De interpretatie? In een model met veel lagen is die vraag zelden snel te beantwoorden. En ondertussen staat jouw project stil.

Uit onderzoek van PMI (Project Management Institute) blijkt dat 57% van mislukte projecten faalt door gebrekkige communicatie. Dat is niet een argument voor betere projectmanagers. Dat is een argument voor minder schakels.

Wat er verloren gaat bij elke overdracht

Je hebt een uur lang uitgelegd waarom een bepaalde checkout-flow cruciaal is voor jouw specifieke klantgroep. Drie weken later levert het bureau een standaard checkout op. In de vergadering zeggen ze: "Dat stond niet in de specificaties."

Wat er verloren ging, was niet de specificatie. Dat was de context. De reden achter de keuze. Het begrip van jouw business.

Een projectmanager kan een lijst met requirements beheren. Wat hij niet kan beheren, is begrip.

Begrip bouw je op door direct te praten. Door vragen te stellen die niet in een ticket passen. Door te merken dat een klant aarzelt bij een bepaalde keuze en daar op in te gaan. Door na drie projecten samen te begrijpen hoe iemand denkt, welke afwegingen hij maakt, wat hij zegt als hij "snel" bedoelt maar "goed" bedoelt.

Dat is wat verloren gaat bij elke overdracht: de menselijke dimensie van een samenwerking.

Hoe wij werken: de developer is de schakel

Wij zijn een klein team van senior developers met meer dan 15 jaar e-commerce ervaring. Geen junior developers die worden ingewerkt op jouw project. Geen accountmanagers die het gesprek openen en daarna verdwijnen. Geen projectmanagers die tussen jou en de code staan.

Wanneer jij een project start bij coding.nl, praat je direct met de developer die het bouwt. Dat is geen marketing-statement — dat is letterlijk hoe het werkt.

Wat dat concreet betekent:

• Je legt een vraag uit, de developer die hem beantwoordt is dezelfde die de oplossing bouwt
• Technische afwegingen worden met jou besproken, niet voor jou beslist
• Als er een keuze gemaakt wordt over Magento, Laravel of een andere technologie, leg je die keuze direct voor aan de persoon die de consequenties ervan begrijpt
• Feedback gaat direct terug naar de code, niet via een tussenlaag die de feedback "verwerkt"

Snelheid is een bijproduct, geen doel. Minder schakels betekent minder wachttijd. Een vraag die anders drie dagen door een systeem reist — van jou naar PM naar developer naar PM naar jou — beantwoorden wij in een gesprek van tien minuten.

Kwaliteit is ook een bijproduct. Als de developer begrijpt waarom iets gebouwd wordt, bouwt hij het beter. Niet omdat hij harder werkt, maar omdat hij de juiste afwegingen maakt.

Wanneer een projectmanager wél nuttig is

We zijn eerlijk: er zijn situaties waarin een projectmanager zinvol is.

Een PM is nuttig wanneer:

• Er tientallen stakeholders zijn met conflicterende belangen die gecoördineerd moeten worden
• Het project gaat over processen en mensen, niet primair over code
• De opdrachtgever zelf geen tijd of capaciteit heeft om betrokken te zijn
• Er contractuele of compliance-redenen zijn die formele documentatie van elke communicatiestap vereisen

Maar voor het overgrote deel van de e-commerce development trajecten — een Magento-migratie, een custom Laravel applicatie, het bouwen van integraties — is een projectmanager de verkeerde oplossing voor een probleem dat er niet hoeft te zijn.

Het probleem is namelijk niet: "We hebben iemand nodig die de communicatie beheert." Het probleem is: "We hebben een team dat groot genoeg is dat communicatie een apart beroep vereist." De oplossing is niet een projectmanager. De oplossing is een kleiner, beter team.

Conclusie: minder lagen, meer resultaat

Het bureau-model met projectmanagers is niet bedacht om projecten beter te maken. Het is bedacht om bureaus schaalbaar te maken. Dat zijn twee verschillende doelen.

Wij hebben gekozen voor het eerste doel. Betere projecten, voor een kleiner aantal klanten, met directe lijnen.

Benieuwd of onze aanpak bij jouw project past? Neem direct contact op — je spreekt meteen met een developer, niet met een accountmanager.

Veelgestelde vragen

Is een development bureau zonder projectmanager niet chaotischer?

Nee. Chaos in projecten ontstaat door miscommunicatie en onduidelijke verantwoordelijkheden. Als de developer direct communiceert met de opdrachtgever, zijn er minder momenten waarop informatie verkeerd begrepen kan worden.

Hoe houd ik overzicht over het project zonder een PM?

Wij werken met korte, regelmatige updates — in de meeste trajecten een wekelijks check-in van een half uur. Jij houdt het overzicht, wij leveren de informatie.

Werkt dit model ook voor grotere projecten?

Ja, binnen grenzen. Voor een Magento-migratie of een complexe Laravel-applicatie werkt het goed. Voor een project waarbij twintig afdelingen moeten worden aangehaakt, zijn wij waarschijnlijk niet de juiste partij.

Wat als ik technisch niet onderlegd ben?

Een ervaren developer weet hoe hij technische concepten uitlegt zonder jargon. Wij leggen altijd uit wat we doen en waarom, op een manier die begrijpelijk is.

Hebben jullie dan helemaal geen interne afstemming?

Wel intern, niet als aparte functie. In een klein team bespreek je vanzelf met elkaar wat je bouwt. Het overzicht zit in de hoofden van de mensen die het werk doen, niet in een spreadsheet.