Regelmatig kom ik in bedrijven tegen dat ze proberen het proces van de it-projecten te uniformeren. Door een eenduidige werkwijze proberen ze het mislukken van projecten te voorkomen. Als iedereen maar hetzelfde werkt, dan gaat er al een stuk minder mis. Nu is dat op zich waar, maar het introduceren van een methodiek is niet de oplossing zelf. Er moet ook eens gekeken worden naar het formaat van de verschillende projecten.
De meeste methodieken schrijven voor dat je eerst een keuze moet maken hoe en welke delen van de methodiek je toepast in je organisatie. Dat wordt dan ook ijverig gedaan, hele boekwerken worden geschreven over de aanpak. Maar toch blijven projecten mislukken. Eén van de redenen is dat in veel organisaties geen keuze gemaakt wordt voor een uniforme omvang van projecten.
Kijk nu eens naar een fabriek; bijvoorbeeld een autofabriek. Zijn productielijn kan, zonder bijstellen, meestal maar één model auto aan. Probeer nu niet in dezelfde productielijn eerst een SUV, dan een sportwagen en daarna MPV te produceren. En dan zijn die verschillen nog niet zo groot. Probeer eens in dezelfde fabriek een vrachtwagen en daarna een personenbus. Ach, doe daarna een 747 want die vervoert ook mensen en er zitten inklapbare wielen onder.
Kijk nu eens naar wat voor soort it-projecten je door in je organisatie naast elkaar wilt doen en dat met dezelfde aanpak en werkwijze. Heel vaak tref ik 'sportwagen' it-projecten naast 'vrachtwagen' it-projecten aan. De ene is met drie man in drie maanden klaar. Aan de andere werkt een team van tien man al twee jaar. En dat probeert men dan met één aanpak/werkwijze.
Mijn pleidooi: wil je echt verbeteren, zorg dan dat je één werkwijze en één soort omvang van je it-projecten hebt. Te grote projecten zijn altijd terug te brengen tot kleinere deelprojecten. Te kleine (change) projecten zijn meestal ook te bundelen tot meer gelijkwaardige (release) projecten.
