Methodologie

Wat ik mij al heel erg lang afvraag, van toen ik nog projecten deed als broodwinning… Buiten de bouw van pakweg een wolkenkrabber of een vette Airbus of Boeing, lukt dat eigenlijk wel, project management-volgens-het-boekje?

Ik kan er de mensen eindeloos over onderhouden hoor, allerlei methodologieën en modellen en PM bloederige BOK en watervallen, en risico-analyse en watnog—maar komt dat er eigenlijk niet gewoon neer op duidelijke afspraken en goede communicatie?

Als ik er over terugdenk, kan ik de potentiële en uiteindelijk echte klanten niet op mijn handen tellen voor wie het een condition sine qua non was dat we een project management-methodologie konden voorleggen. En nu ik meer met leveranciers werk, zie ik ze ook effectief allemaal afkomen met hun methodologieën en schemaatjes en spreadsheets en critische paden… tssk.

Nee, het interesseert me eigenlijk hoegenaamd niet welke methodologie er gevolgd wordt. Als het maar werkt. Ik vraag me niet af om de hoeveel dagen er een nieuwe GANTT chart opgestuurd wordt, maar ik ben wel geïnteresseerd in referenties. Vorige en huidige klanten met wie ik een klappeken kan doen.

En die ik meteen kan vragen hoe het ermee zit.

Ter illustratie. Een hele tijd geleden, in een vorige werksituatie en toen de dieren nog spraken, zat ik in een positie waar er tussen twee technisch en financieel gelijkwaardige bedrijven gekozen moest worden voor het programmeren van een complex ding. Call for Tender, Request for Proposals, vergaderingen allerlei, enfin, we waren al twee maand ver. Bedrijf één zei me dat ze wel heel veel referenties hadden, maar niet echt iets dat meteen helemaal toepasselijk was, maar goed, ze zouden me wel een folder opsturen. Bedrijf twee gaf me een lijst van contactpersonen bij klanten, zei me dat ik ze allemaal mocht contacteren, en stelde voor me mee te nemen voor een gesprek met een klant die ongeveer hetzelfde wou als wat ik wou.

Twee keer raden wie de applicatie heeft mogen programmeren.

5 reacties op “Methodologie”

  1. Ik heb er morgen voormiddag cursus over, ik zal de vraag eens stellen.
    Vooral binnen complexere of grotere organisaties denk ik dat fatsoenlijk project management wel zinvol is, ook voor kleinere projecten. Omdat aan de hand van bv. milestones de evolutie van een project beter kan geëvalueerd worden, en van hogerhand kan bijgestuurd worden. Of omdat de beslissers niet noodzakelijk op de hoogte zijn van de technische kant, en dus een uitgewerkte methodologie nodig hebben om een gefundeerde beslissing te nemen.
    Maar het is allemaal inderdaad nogal relatief, en dikwijls veel blabla.

  2. Helemaal mee eens: methology doet er niet zoveel toe, als je het werk maar kan structureren en afspraken kan maken over hoe en wat je doet.

    Het moet ook geen papierschuiven om het papierschuiven worden.

  3. Eerlijk gezegd, ik ben een enorm voorstander van Agile en probeer dat ook zoveel mogelijk toe te passen.Veruit het ergste wat ik al gezien heb is het toepassen van RUP in kleine projecten -en in grote projecten ook- want daar wordt zoveel aandacht besteed aan die architecture milestone dat het bijna altijd uitdraait op over-engineering met als resultaat over-budget en -time. Ooit gezien hoe iemand in zijn eentje (!!) een volledige J2EE applicatie aan het bouwen was met RUP die uiteindelijk door exact twee mensen ging gebruikt worden. Ik had hem en zijn projectmanager een nekschot willen geven om hen uit hun lijden te verlossen…

    Ik heb mijn buik vol van methodologisten. Ik weiger bv de solliciteren bij een bedrijf dat ook een vacature heeft openstaan voor methodologist. Dan weet ik al hoe laat het ginder is en wil ik er niets mee te maken hebben. Bij mijn vorige werkgever werden ze allemaal geil van die dingen. Een groot project begonnen in de ene methodologie en wanneer bleek dat het schandelijk over-time en -budget ging -duh, het was RUP- hals overkop overgeschakeld op een andere methodologie…extreme programming dan nog.

    Nee, geef me dan maar Agile…dat ruikt naar pragmatisme 😉

  4. Speaking as project manager, pragmatisme is “key”. Methodologie vormt een framework, een denkwijze, een referentiekader – maar meer ook niet. Ik gebruik het als ik het nodig heb, en als het niet past binnen de tijdslijnen van het project … spijtig, dan gebruik ik wel een “light-versie”.
    Een methodologie bestaat toch alleen om projecten te helpen, de bestaansreden van een project is toch niet om een methodologie te volgen – maar om produkten uit te brengen, om applicaties te bouwen, of vliegtuigen natuurlijk.

  5. Ik heb methodologieën uitgebouwd en ben projectleider geweest, en binnen een zestal weken ga ik de twee terug combineren.

    Eigenlijk vat Martin Wisse zijn commentaar alles samen. De bedoeling is het werk te structureren, te plannen en goede afspraken te maken en dat is dus eigenlijk wat een goede methodologie hoort te zijn.

    Maar meestal wordt een prefab-methodologie van het schap gehaald en niet pragmatisch aangepast aan het uit te voeren project en dan krijg je inderdaad van dat nutteloze papierschuiven.

Reacties zijn gesloten.