In control over projectsucces (3)

In dit derde en laatste deel van ‘in control zijn over projectsucces’ gaat Marcel Seijner in op ‘in control zijn’ als strategie, niet als managementtool. Het gaat over innovatie, verantwoordelijkheid, vertrouwen, veiligheid en over waarde(n) en normen.

In het eerste deel ging het erover dat projectsucces meer is dan: ‘Binnen budget, op tijd de juiste kwaliteit en scope te bereiken’. Projectsucces ook gaat over customer loyalty, team satisfaction, return on investment en klaar zijn voor de toekomst. Het tweede deel ging erover, dat er een cultuurverandering nodig is om in balans te komen en successen te behalen voor alle stakeholders. Project control gaat dus niet over het voorspellen en het bereiken van de voorspelde waarden, maar over gezamenlijk doelen bereiken en op een beheerste manier bijsturen oftewel beheersen, waarin iedereen zijn deel krijgt en iedereen tevreden is. Wel is het belangrijk om te weten wat de bandbreedte is waarbinnen gestuurd wordt.

Resultaatgericht of doelgericht

Als er wordt gesproken over projectsucces en over ‘in control zijn’ kunnen we onderscheid maken tussen twee soorten projecten.

Type 1: projecten die uitgevoerd worden voor klanten.
hierin kan een variëteit aan contractvormen zijn (bijvoorbeeld vaste prijs, turn-key, op basis van nacalculatie en op basis van regie).

Type 2 projecten voor de interne organisatie. (Archibald, 1993).
Een belangrijk verschil met type 1 projecten is dat in veel gevallen type 1 als inkomstenbron gelden in het businessmodel van maakindustriebedrijven (o.a [scheeps-]bouw-, ICT-, installatie-, en productiebedrijven). Bij type 2 projecten zijn projecten meestal onderdeel van een intern (verbeter-)programma. Voorbeelden hiervan zijn: marktintroductie van een product, verbeteren of verduurzamen van het productieproces, veiliger maken van een wijk , software-implementatie, efficiënter werken etc..

Bij type 1 projecten ligt de focus meer op efficiency, productiviteit, doorlooptijd, binnen budget blijven, alles conform contract en eisen van de opdrachtgever, kortom resultaatgericht. Bij type 2 projecten ligt de focus meer op het halen van doelen, zoals verhogen ROI, introductie van nieuwe producten, ontwikkelen van nieuwe technologieën.. Hier zit tevens het verschil in aansturen. Aansturen op details en efficiency of op benefits, doelen, milestones of minimum viable product (laatste term is uit Lean Start Up van Eric Ries, 2013).

Waar wil men over in control zijn?

Als mens wil men graag in control zijn, de baas zijn over een koers die men heeft uitgezet. Als ondernemer wil men dat ook. Dat kan zijn door 1. een nieuw product te lanceren of 2. een project aannemen voor een bepaalde prijs. In het eerste geval wordt geïnvesteerd en wordt er van uitgegaan dat na marktintroductie inkomsten gegenereerd worden. In de tweede situatie geldt dat een project een investering is om doelen (omzet en winst) te behalen.

Het risico vindt in het project plaats en bestaat er voor het grootste deel uit of de doelen wel worden behaald met het beoogde resultaat. In geval 1. gaat de ondernemer iets maken voor een klant, een resultaat met een bepaalde scope, met afspraken over prijs, kwaliteit en deadlines, mogelijk over de te behalen doelen en eventuele functionaliteiten en onderhoud. In het tweede geval zit het risico meer in het conform contract leveren. Met name over de risico’s wil men in control zijn. Hierin zit namelijk de toegevoegde waarde van de organisatie, het business model.

Het probleem begint als organisaties groter worden. De directie zet de koers uit, marketing zorgt voor de aandacht, verkoop haalt de klussen binnen of de stuurgroep bepaalt de business case, voorstellen worden gemaakt, eisen worden opgesteld, ontwerpers ontwerpen het resultaat, inkopers kopen in, uitvoerders realiseren het afgesproken resultaat, testers testen het resultaat op basis van vooraf gestelde eisen en tot slot is de klant blij met het resultaat.

Vanzelfsprekend! is dat ook zo?

Dat wel, maar uit de vorige zin blijkt ook iets wat dit succes in de weg staat: hokjes denken, functioneel organiseren. Hier gaat het fout. De klant heeft iets in het hoofd, een verkoper of intern opdrachtgever beeldt zich in wat wordt bedoeld, vertaalt dit naar een concurrerende prijs of een budget en een schets of een voorlopig ontwerp, er wordt een budget geschat, de ontwerpers komen er achter dat het voorlopig ontwerp niet mogelijk is, de prijs is te scherp, er moet efficiënter worden gewerkt, er wordt bespaard op kosten en uitgaven, materiaal en mensen, de kwaliteit en deadlines staan onder druk en te laat wordt een te duur, mislukt product of dienst opgeleverd. Klant niet blij, projectleider niet blij, projectleden niet blij, opdrachtnemer niet blij, niemand blij. Een doemscenario dat nog steeds maar al te vaak voorkomt.

Hoe dan wel?

Voor interne projecten, type 2, wordt steeds vaker, vooral bij ICT-projecten, Agile als heilige graal genoemd en wordt na Scrum ook Continuous Delivery en DevOps methodieken gebruikt. Ook voor type 1 projecten wordt dit geregeld als optie genoemd. Hier moeten we echter een pas op de plaats maken. Eerst moet worden gedefinieerd wat het doel is, wat is het projectsucces? Als we de meest vooruitstrevende projecten bekijken, dan is er maar één gezamenlijk doel en dat is dat alle stakeholders tevreden zijn/worden. Dat betekent eigenlijk: er wordt op termijn voor de opdrachtgever een product opgeleverd, waarmee deze zijn doelen kan behalen. Die termijn is niet altijd vast. Dit is meestal een wens of een streefdatum. Tenzij er een harde deadline aan gekoppeld is vanuit bijvoorbeeld wetgeving.

Budget wordt vaak ook niet vooraf vastgesteld. Het gaat er alleen om wat de terugverdientermijn is (ROI). Zelfs kwaliteit valt door de opdrachtgever nog flexibel te interpreteren. Natuurlijk zijn er HCCP, ISO of andere Europese normen, maar functioneel gezien zijn er minimale en maximale eisen. In deze situaties is het zelfs mogelijk om het projectmatige geheel te verlaten volledig na het opleveren van een eerste release ‘continuous delivery’ toe te passen. Hier geldt wel de vraag: ‘Waarover is men dan eigenlijk in control?’ In ieder geval niet over de investeringen omdat hier de realisatie een productie-afdeling is geworden en er geen sprake is van een afgerond project. De vraag is of dat wenselijk is.

Oplossingsmogelijkheid

Als de wens is om toch projectmatig te blijven werken dan kan er een combinatie gemaakt worden van diverse principes en methoden. Het MoSCoW principe voor de scope (eerst de Must haves, dan de Should haves en tot slot de Could haves maken als het budget en de tijd het toestaat) en dit kan ook worden toegepast op kwaliteit; wat is de minimum eis voor een eerste prototype (minimum viable product)?

Qua tijd, budget en risico’s kan worden gewerkt met de Critical Chain gedachte van Goldratt, zo strak mogelijk plannen, qua budget, tijd en risico’s, de ruimte wordt er uit gehaald en wordt gebufferd en gebruikt als het toch niet wordt gehaald. Samenwerken en afstemmen is hier cruciaal. Kritieke resources worden leidend in het proces ingezet. Bovendien wordt de planning niet door de opdrachtgever opgesteld, maar in gezamenlijke verantwoordelijkheid (last planner en lean plannen) en zelfs het budget wordt niet vooraf vastgesteld maar wordt afhankelijk van de terugverdientermijn en wordt gedurende het project steeds concreter (Bjarte Bogsnes, Beyond Budgetting).

En als alles vooraf kan worden gespecificeerd en begroot en als de voortgang goed te bewaken is, dan pas volstaan methodieken als Earned Value Analysis, PERT, kritieke pad, slip chart (voorloper van de burn-down-chart), WBS en tijd-weg diagram ook prima.

Hoe dan wel ‘in control’?

‘In control’ is niet inspecteren, controleren, bewaken (Homan slaat hierin in zijn boek ‘In control’ de plank redelijk mis). In control zijn betekent, nogmaals, niet over het voorspellen en het bereiken van de voorspelde waarden, maar gezamenlijk doelen bereiken en op een beheerste manier bijsturen oftewel beheersen, waarin iedereen zijn deel krijgt en iedereen tevreden is. Samenwerken is dus niet het Angelsaksische “you lose silver and you win gold”, maar alle partijen moeten winnaars zijn, geen competitie, een redelijk Rijnlandse gedachte. Een opdrachtgever die samenwerkt met een opdrachtnemer, concurrenten die samenwerken, belangen delen. Een ondernemer moet risico’s nemen, dat behoort bij het ondernemerschap, maar niet roekeloos. Roekeloosheid is het tegenovergestelde van in control.

Een bergbeklimmer bereikt ook doelen en is in control en heeft zich uitermate goed voorbereid, maar tijdens de klim komt hij steeds weer voor nieuwe uitdagingen te staan. Om het resultaat te bereiken en het doel, zullen, zeker in complexe situaties, nieuwe investeringen in tijd en wellicht geld moeten worden gedaan. De vraag is echter of de Mount Everest-beklimmer in control is gebleven als hij/zij een bevroren teen overhoudt als hij de top heeft bereikt. Dit risico zat er in en is genomen, neemt niet weg, dat dit risico waarschijnlijk is ingecalculeerd. Desondanks is de bergbeklimmer dan in control gebleven, hij is situatie de baas gebleven.

Dus in control van projectsucces gaat zeker ook over een goede voorbereiding, goed visualiseren (projecteren), goed ontwerpen, goede eisen stellen, goed uitvoeren, goed testen, echter om het te bereiken is efficiency niet heilig, maar beheersen, bewaken en bijsturen op alle succesfactoren van alle belanghebbenden wel. Dat kan alleen als er openheid, vrijheid, veiligheid, verantwoordelijkheid, gedeelde waarden en bevoegdheid aanwezig zijn. Ook moet niet uit het oog worden verloren dat een project ook een succes kan zijn als er wordt geleerd. Dit kan een doel op zich zijn: validated learning (Eric Ries, 2011).

Onzekerheden

Elk project heeft onzekerheden, anders werd het niet projectmatig uitgevoerd. Sommige projecten of onderdelen van een project zijn voorspelbaar, te ontwerpen, met voorspelbare onzekerheid, andere onderdelen hebben een onvoorspelbare onzekerheid (Sylvain Lenfle, 2016). Bij het voorspelbare deel zijn uitstekend eerder genoemde standaard beheersinstrumenten te gebruiken, bij onvoorspelbare onzekerheid is dat niet verstandig, dit komt namelijk in conflict met het innovatievermogen van het project. Als innovatievermogen belangrijk is (met name in type 2 projecten, kan beter gestuurd worden op doelen, niet op resultaat omdat het resultaat niet vast staat. Ook de scope staat niet vast en kan derhalve niet gestuurd worden met methoden als Earned Value en dergelijke.

Control en innovatie

Projecten hebben veel kenmerken om innovatie te stimuleren;, vrijheid, verantwoordelijkheid, autonomie en het vertrouwen op vakmanschap, Kenmerken van projectmanagement welke innovatie ondersteunen (Keegan and Rodney Turner, 2002) zijn onder andere:

• Elaborate information processing and co-ordination mechanisms
• Widespread formal and informal communications
• Blurring of organisational boundaries
• Integrating personnel, boundary spanners and matrix structures
• Considerable stress and ambiguity for managers and workers
• Bottom-up emergent strategies shaped by managers
• Flexible roles determined through interaction between organization members
• Managers facilitate projects rather than control projects
• Decentralisation of authority and deconcentration of power
• Effectiveness – not efficiency – emphasised
• Multi-disciplinary project teams comprised of members of different functions perform work

Wat Keegan en Rodney Turner in datzelfde artikel ook concluderen is dat projectmatig werken per definitie innovatief is omdat het altijd een uniek resultaat oplevert, altijd een ontwerp op maat wordt geleverd en er altijd iets nieuws wordt geleverd. Eigenlijk zijn projecten een perfecte basis voor innovatie vanwege de multidisciplinaire teams, intensieve communicatie tussen verschillende functionele groepen, vrije toegang tot informatie, besluitvorming op basis van expertise. Echter als er planning en control-systemen worden toegepast heeft dat een negatieve invloed op ondersteuning van innovatie. Innovatie wordt zelfs vaak gezien als risicovol, kostbaar en vaak gevaarlijk.

Dit dilemma tussen innovatie, beheersing en voorspelbaarheid en de behoefte aan ‘control’ kan mogelijk met nieuwere methoden als Continuous Delivery en DevOps worden opgelost om in control te zijn, echter in control van wat? Dat software continu wordt ge-update? Zijn dat echte innovaties? Dat geleverde producten (software) continu worden onderhouden door samenwerking tussen ontwikkelaars en beheerders? Dit heeft niets meer met projectmanagement te maken maar hiermee is het ontwerpen van producten weer terug bij productieafdelingen en werkplaatsen die seriematig producten maken, maar dat kan ook een doel op zich zijn.

Conclusie: in control willen zijn is menselijk

Iedereen wil in control zijn, dat is een menselijke eigenschap en heef te maken met lijfbehoud. We willen in control zijn over ons lot, over onze toekomst. Wij hebben het tijdperk verlaten dat anderen over ons lot beschikken. Dat betekent ook, dat als wij als verantwoordelijke en bevoegd gezag, verantwoordelijkheden en bevoegdheden delegeren aan onze ondergeschikten of beter, partners. Zij moeten ook in control willen zijn over wat aan hen is toevertrouwd.

Dit essay weerhoudt ons zeker niet van ‘in control’ zijn over scope, tijd, geld en kwaliteit. Deelprojecten met voorspelbare onzekerheid kunnen prima gepland worden en op traditionele manier geleid worden met burn down charts, earned value analysis, slip charts, milestones, WBS, PERT, Gantt Charts, standlijnen, etc. al was het alleen maar om het toch zo spoedig mogelijk, zo goedkoop mogelijk, zo goed mogelijk, met zo min mogelijk verspillingen resultaten op te leveren om zo spoedig mogelijk doelen te behalen. Deelprojecten met onvoorspelbare onzekerheid kan men beter op een iteratieve manier leiden met minimal viable products, scrum, sprints, story boards, prototypen, DevOps, Continuous Delivery, etc. Ook is een tool als BIM (Building Information Modeling) hier uitermate geschikt voor om inzicht te geven hoe het eindproduct er uit kan komen te zien. Het gehele project of programma kan dan gestuurd worden op doelen en benefits, hierbij moeten de visie en functionele eisen goed worden beschreven en hierop moet vervolgens worden genavigeerd.

Als men ‘in control’ wil blijven over projecten, moet men vooraf afspreken waarover men in control wil zijn en daarop de projectmanagent-methodieken afstemmen.

Ik wens u veel mooie (project)resultaten.
Marcel Seijner

Verder lezen?

• R. Archibald, ‘Re-tooling the project driven organisation’, ?PM Network 6–10 1993
• Anne Keegan, Joe Rodney Turner, the management of innovation in project-based firms, long range planning journal, 2002 ?
• Eric Ries, The lean Start-up 2011
• Sylvain Lentle, When project management meets design theory: revisiting the Manhattan and Polaris projects to characterize “radical innovation” and its managerial implications, project management journal; 2016
• Sylvain Lentle, Floating in Space? On the Strangeness of Exploratory Projects, project management Journall; 2016