Eigen wijsheid en common sense in (project) management

Op basis van 10 jaar ervaring in Banking – ICT projecten: Bestaat Agile Projectmanagement nog?

Auteur: Iwanjka

 

“Een pleidooi voor het ‘edele’, Agile Projectmanagement”

 

Sponsors ICTSociety projecten:

 

 

 

Inhoud

1.         Algemene stellingen en observaties over projectmanagement

1.1.      Welke projectmanager hanteert nog common sense?

1.2.      Enkele losse noten

- Offshoring

- Titels en certificaten

- MS Projects

- Verhouding projectmanagers vs ontwikkelaars

- Methodeisme of methodekramp

- Projectduwen of projectmanagement?

- Best practises m.b.t. het uitbesteden van projecten voor de opdrachtgever

 

2.         Over fixed price / time project management

2.1.      Projectbeheersing bij fixed price / time projecten, gebruik Excel en metrieken

2.2.      Best practises m.b.t. het uitbesteden van projecten voor de opdrachtgever

___

 

1. Algemene stellingen en observaties over projectmanagement

 

1.1. Welke projectmanager hanteert nog common sense?

Een van mijn grootste ergernissen in de ontwikkeling van het vak projectmanagement is het feit dat geen enkele projectmanager meer in staat lijkt om zonder een template een deugdelijk projectplan te schrijven. Projectmanagement verwordt tot het invullen van tientallen templates voor risklogs, diverse projectplannen, architectuurdocumten, etc. Vervolgens is de projectmanager ook nog gehouden aan het volgen van een vast stramien voor het uitvoeren van zijn project.

 

Ik geloof hier niet in. Ik denk dat het leidt tot zo minimaal 80% efficiency verslechtering. Mensen denken veel minder zelf na. Het fenomeen versterkt zich omdat de organisatie het hanteren van dergelijke bureaacratische methodes afdwingt. Je moet wel. Het is goed om eenzelfde taal te spreken, en best practises vast te leggen. Wellicht een aantal templates die je bij voorkeur gebruikt, maar daar houdt het wel op. 9 van de 10 projecten die ik zag, die waren procestechnisch goed ingeregeld maar feitelijk scoorden ze een zware onvoldoende. En al helemaal op inhoudel vlak: door te focussen op het proces, was er geen focus op de inhoud: hoe ga je het probleem / vraagstuk ICT technisch eigenlijk oplossen? Hoe vaak heb ik niet enorme systemen gebouwd zien worden waarvan bij aanvang al mensen met inhoudelijke visie zeiden: “dit gaat niet werken”. Toch doen, en na een jaar of drie en enkele miljoenen euro’s verder, kon het systeem de prullenbak in.

 

Voor mij is projectmanagement:

·        Helder krijgen wat de vraag of wens is

·        De oplossing bepalen (inhoud)

·        Een plan bepalen hoe daar te komen (proces in combinatie met inhoud)

·        Het proces managen / organiseren

 

Hierbij is een activiteiten- en systeemdcompositie het primaire instrument. Dit kan in twee Excelsheetjes. Het bijzondere is dat ik dit primaire instrument in geen enkele projectmanagementcursus terug heb zie komen. Voelen we ons hier te goed voor? Het treurige is dat ik deze manier van het project managemen ook praktisch niet in de praktijk zie...

 

Voor mij is het 2e primaire onderdeel een globale oplossingsbeschrijving. Deze moet al vrij snel op papier staan: welke technologie, hoe lopen de processen globaal, hoe gaan we het invoeren, testen (parallel runs met productie?), etc. Dit document is de kapstok voor alle andere projectmanagementdetaillering. Ook een dergelijke deliverable zie ik niet terug in de diverse cursussen, methodielen, etc. Ik snap dat niet.

 

 

 

1.2. Enkele losse noten:

·        Offshoring: geloof ik niet (meer) in. Ik heb het allemaal mogen meemaken: opkomst van off shore development (zie ook het artikel ‘Offshoring stelt organisaties zwaar onderdruk, Automatiseringsgids 2002), het werken met Indiers en Pakistaans ICT-ers en het zien hoe het veelal allemaal flopt en het management zichelf en de buitenwereld een rad voor ogen draait. Kreten als ‘maar het is wel goedkoper’, of ‘we voeren wel meer functiepunten uit’. Zo vaak loze kreten, waarbij niet gezien wordt dat er misschien 10% minder geld uitgegeven wordt aan ICT, maar dat gelijkertijd de feitelijke  ‘ICT productie’ en de toegevoegde waarde voor de business naar een nulpunt zakt. Sterker nog: flexibileit en slagkracht van de organisatie neemt af. Creatieprocessen worden geblokkeerd door megalomane procedureberschrijvingen, methodieken en managers. Nog nooit zoveel ‘managers’ zien rond zien lopen als de afgelopen jaren: projectmanagers, programmamanagers, testmanagers, ketenmanagers, methodemanagers, kwaliteitmanagers. En allemaal trekken ze aan dezelfde 1 of 2 ontwikkelaars of ontwerpers die het werk eigenlijk doen.

Ik geloof overigens wel in global software development in de vorm van open source. Het grote verschil met offshoring is dat er een meer ‘edele’ drijfveer achter zit (geen winstbejag).

·        Het aantal titels en certificaten dat een (project) manager heeft is over het algemeen tegengesteld evenredig met diens toegevoegde waarde. Anders gezegd: hoe meer titels, hoe groter de kans dat de beste man of vrouw niet in staat is op common sense een project te organiseren (anders had je al die titels niet nodig om je te handhaven, c.q. had je geen tijd om al die opleidingen te volgen of zag je het nut er niet van in). Ik besef me dat ik met deze stelling een ‘dwarse noot’ ben, maar ik geloof in een eigen geluid. Deze stelling is tot op heden in de praktijk niet ontkracht...

·        MS Projects: Meer doen met MS Project dan een ‘praatplaat’ maken is niet zinnig. Deze moet op 1 a4tje passen. Projecten waar de muren vol hangen met MS Project schema’s wantrouw ik. Mooie platen, maar niet bij te houden, praktijk wijkt af, etc. Dit geldt ook voor MS Projects gebruiken voor resourceplanning, budget, etc. Doe ik niet. Excel werkt sneller en accurater. Bovendien kun je dan de voor jou echt belangrijke kentallen produceren (zie ook de grafiken verderop, waarop al na drie weken na de start je eigenlijk weet of het project op tijd opgeleverd wordt = directe toetsing van capciteitscalculatie).

·        Verhouding projectmanagers vs ontwikkelaars mag niet groter zijn dan 1 op 4. Als dit wel het geval is, dan deugd de projectorganisatie niet. Ik heb regelmatig 3 projectleiders aan het bureau van 1 modelleur zien staan. Verwonderde blik in de ogen van de modelleur...

·        Over Methodeisme of methodekramp: Zoal eerder gesteld in dit document: groteske methode handboeken zijn slecht. In mijn ogen ontstaan deze veelal als degene die hierover gaat (of de afdeling, de mensen die het toepassen, etc.) de methode op zich tot doel gaat verheffen. De methode gaat zichzelf opblazen. Dit is een organisch proces en je ziet het overal terug, of het nu een ministerie is, dat zelf gebaat is bij meer regels, of een consultant die een gebaat is bij het adviseren bij een bepaalde oplossing om vervolgens al zijn consultantbroeders naar binnen te rollen. Het is een zelfdestructief mechanisme. De methode vervaagt verantwoordelijkheid: ‘we hebben gewoon de methode gevolgd’, of door het bizarre aantal rollen is niemand meer verantwoordelijk. Verder is ‘procesmanagement’ cooler dan ‘inhoud’, een belangrijke reden waarom er volgens een ‘mooi’ proces vaak onzinnige dingen gebouwd worden.

·        Projectduwen of projectmanagement? Te weinig zie ik nog het ‘edele’ projectmanagement: zuiver decompeneren, calculeren en managemen. Bij tolerantie overschrijdingen van 5% in termen van geld, risico of tijd bijsturen, etc. Soms lijkt het projectmanagement meer op ‘projectduwen’ of ‘kudde drijven’. We gaan duwen en hopen dat er ooit een einde aankomt. De projectmanager lijkt dit zelfs soms wel fijn te vinden. Die houden van choasmanagement of vinden het organiseren van de ‘details’ geneuzel waar zij zich niet mee bezig moeten houden. Opdrachtgevers doen hier vaak aan mee door zelf ‘te rommelen’: niet luisteren naar de projectmanager. Projectmanagers zegt dat het niet kan. ‘Nou, doe toch maar’. Als het niet kan, en dit blijkt herhaaldelijk, dan is het mijn visie dat er iets anders moet veranderen: wellicht is het samenstel van ICT-producten-processen te complex geworden. Dan moet je eerst daar in gaan snoeien. Wellicht nieuwbouw in plaats van een spinneweb van systemen proberen aan te passen, etc.

 

2. Over fixed price / time project management

 

2.1. Projectbeheersing bij fixed price / time projecten

Onderstaande platen komen uit het mooiste project waaraan ik ooit een bijdrage heb mogen leveren. Helemaal volgens het Agile Projectmanagement hart. En ook nog (ruim) binnen budget, on time, geen productverstoringen en tevreden gebruikers...

 

Met name bij een fixed price / date project is het cruciaal om zo snel mogelijk zicht te krijgen op in hoeverre de opgestelde planning reëel is. Een standaardactiviteit bij het maken van een projectplan is het maken van een inschatting per deelactiviteit. Vaak wordt er ook nog een FPA (Functie Punten Analyse) uitgevoerd, of worden heuristieken van eerdere –vergelijkbare(!)- projecten erbij gehaald.

 

Vervolgens verdwijnt het projectplan helaas in de kast, terwijl de echte projectbeheersing nu pas begint. In het referentie fixed project (zie CV) is op wekelijkse basis van elke projectlid het aantal gemaakte uren plus de bijbehorende activiteit geregistreerd in een speciaal daartoe opgezette Excel spreadsheet. De spreadsheet rekent vervolgens per activiteit door wat per activiteit de behaalde productiviteit versus de geplande productiviteit is. Door vervolgens de resterende hoeveelheid werk in te schatten ontstaat hieronder staand figuur:

 

Factor ‘sneller dan gepland’

 

In het figuur zijn twee schattingen opgenomen: de ene schatting is van de projectleider die op basis van zijn inzicht per activiteit een ‘percentage gereed’ schatting geeft. De andere schatting is van de lead developer die –zonder dat hij weet hoeveel uur op de activiteit besteed is- een schatting afgeeft op hoeveel uur er nog nodig is om de activiteit af te ronden. Op deze manier wordt zeer snel inzichtelijk (al na 2 of 3 weken) of de oorspronkelijke planning correct is, of dat er al bijgestuurd moet worden. In bovenstaand schema is duidelijk te zien dat de productiviteit langzaam oploopt (dit komt omdat in het begin diverse instelkosten genomen moesten worden, nieuwe developers ingewerkt moesten worden, etc.), om vervolgens op een piek te komen (+/- 1,25) en vervolgens zakt naar de uiteindelijk behaalde rendement (+/-1,21). Dat de productiviteit weer is gaan zakken komt omdat aan het einde van het project de werkzaamheden wel gereed waren, maar dat het team nog wel aanwezig moest zijn voor nazorg.

 

Aantal uur ‘nog nodig’ vs ‘gepland nog nodig’

Een ander figuur laat zien hoeveel uur er op basis van de hierboven genoemde schattingen nog nodig is vs het geplande aantal nog noodzakelijke uren op moment X. De donkerblauwe lijn moet op of onder de paarse lijn liggen. Ongeveer in het midden van het traject viel de planning buiten de 5% tolerantie (het traject liep 5% achter op planning). De projectleider heeft dit direct gesignaleerd naar de stuurgroep inclusief stuurmaatregelen, het betrof hier enerzijds het instellen van overwerk en anderzijds het beter organiseren van een aantal faciliteiten aan de kant van de opdrachtgever. Vervolgens is te zien dat het project weer ingelopen is, en zelfs onder de paarse lijn (= voor op planning) gedoken is.

 

 

Op de hierboven manier kan op een veel objectievere en gedetailleerdere manier projectbeheersing georganiseerd worden, dan in het geval dat de metrieken niet voorhanden zijn en dat alleen op basis van een mijlpalen planning, of nog erger alleen op basis van een ‘gevoel’ gemanaged wordt.

 

2.2. Best practises m.b.t. het uitbesteden van projecten voor de opdrachtgever

Een (kanditaat) opdrachtgever moet er rekening mee houden dat een  commerciële dienstverlener al tientallen van dergelijke projecten uitgevoerd heeft en precies weet waar ze op moet letten bij het vaststellen van de scope, verantwoordelijkheden en commerciële afspraken. Dit speelt met name voor opdrachtgevers in de non profit sector waar het ‘commercieel denken’ niet een kern is in de dagelijkse gang van zaken.

 

Enkele voorbeelden die vaak fout gaan:

1.      Resultaten worden niet SMART genoeg benoemd. Vervolgens wordt de oplossing ‘goedkoop’ aangeboden, maar wordt e.e.a. door diverse meerwerkacties toch duurdere dan beoogd. Op zich is het in eerste instantie ‘prettig’ werken met een dergelijk aanbieder: de offerte en contract zijn lekker vlot gemaakt, maar vervolgens begint de ellende, voorbeelden uit de praktijk:

·         Het is niet duidelijk hoe aangetoond wordt dat de opgeleverde functionaliteit voldoet.

·         Het is niet beschreven wie de functionele tests uitvoert.

·         Het is niet beschreven wie de functionele testscripts maakt (hier kan heel veel tijd in gaan zitten!)

·         Het is niet beschreven wie de testomgeving(en) inricht.

·         Het is niet beschreven wat er gedaan wordt met meerwerk door fouten of onverwachte werking van gebruikte componenten van derden.

Het is zaak zelf de verantwoordelijkheid te nemen afspraken SMART te maken en de leverancier middels strak projectmanagement te laten voldoen aan zijn verplichtingen zonder dat hier een hogere prijs voor gerekend wordt.

2.      Er wordt geen goede stuurgroep ingericht waarin zowel (juiste partijen van) de opdrachtgever als de aanbieder vertegenwoordigd zijn.

3.      Afspraken worden gedurende het project niet goed vastgelegd: een fixed price / date project is net een huwelijk: zolang alles goed gaat is iedereen heel gemakkelijk, maar zodra iemand op moet draaien voor e50.000,- extra gemaakte / te maken kosten wordt de stemming grimmiger. Het is voor beide partijen veel prettiger om altijd te kunnen terugvallen op duidelijke afspraken.

4.      (Potentieel) meerwerk wordt gedurende het project niet goed vastgelegd: het is zaak zo mogelijk altijd uren die potentieel meerwerk zijn vast te leggen. 1x per twee weken wordt door de stuurgroep de lijst geëvalueerd en per punt besloten wie de uren neemt. Door dit al gedurende het project te doen worden zeer snel mogelijke ontsporingen onderkend en wordt voorkomen dat de opdrachtgever aan het einde van het project verrast wordt met ‘een stuwmeer aan meerwerkuren’. Een erg prettige manier van werken is het indelen van de uren in drie categorieën, en de uren vervolgens middels een vaste verdeelsleutel toe te wijzen: fout van opdrachtgever, fout van aannemer of samen fout.

 

Project uitbesteed: klaar?

Elke uitbesteed project kent een intern project als tegenhanger! In het contract / plan van aanpak staan ongetwijfeld een hele rij afspraken waar de opdrachtgevende partij aan moet voldoen: het tijdig opleveren van specificaties, testcapaciteit, infrastructuur, etc. Indien deze niet op tijd geleverd worden, dan zal dit direct –terecht- resulteren in extra kosten. Het is dus cruciaal dat –naast het managen van het externe project- het interne project strak gemanaged wordt. De hoeveelheid effort die hierin gaat zitten moet niet onderschat worden.