De Projectmanagementstroming die werkt in de industriële automatisering
Leestijd 6 – 7 minuten
Een stroming is een manier van denken die in een bepaalde tijd heerst, er is dan sprake van bijvoorbeeld artistieke, geestelijke of politieke verwantschap; het kan alle vormen van kunst betreffen. Ontstaan door meningsverschillen. Wees gerust ik ga hier niet lopen prediceren wat voor godsdienst of politieke partij nu het beste is. Wat je wel ziet is dat, na meningsverschillen of probleem stukken, nieuwe stromingen ontstaan. Zo ook binnen de jungle van het projectmanagement.
We proberen orde in de chaos te scheppen door georganiseerd, voorbereid en gepland projecten aan te pakken. Zoveel projectmanagers, zoveel meningen over de aanpak van. Allen hebben een gezamenlijk doel; binnen de gestelde tijd en budget een kwalitatief goed product leveren.
Projectmanagement heeft ook pas zin als er een bepaalde complexiteit bij het project komt kijken. We moeten allemaal de kliko aan straat zetten en dat is voor sommigen ook een heel project om uit te voeren. Maar we gaan hier geen projectmanager aan zetten om de kwaliteit, tijd en het budget te beheren.
Cursussen
Ik kreeg les van een ervaren projectmanager tijdens de masterclass Technisch Projectmanagement. Een gedreven man die met passie voor het traditionele projectmanagement voor de klas stond. Volgens hem was de traditionele manier DE manier van project beheersing. Zo was hij onderdeel van het projectmanagement team voor de nieuwe rondweg bij Maastricht. Na een project van meerdere jaren werd in december 2016 de tunnel geopend. Dit was volgens de initiële planning tot op de dag gehaald, wat overigens een hele prestatie is. Hiernaast heb ik ook een Scrum masterclass gevolgd. Gedreven en vol passie is een Agile vorm van project beheersing de manier van aanpakken – meest efficiënt. Dat is preken voor eigen parochie natuurlijk. Ik heb overigens in beiden klassen met plezier gezeten!
In mijn tijd bij ALE-heavylift, binnen de R&D afdeling, was het control system team nog niet heel oud en waren wij bezig een groei te maken naar volwassenheid. De kennis was er zeker, nu het uitbaten van de kennis nog. Met alle neuzen dezelfde kant op waren we vol enthousiasme begonnen aan de Scrum methode. Binnen no-time was er een Excel vol met VB script code waarin alle projecten en taken stonden. Per sprint konden we aangeven aan welk project en hoeveel tijd per project we besteedden. Automatisch kwamen de prio’s naar voren van dat specifieke project. Tegenwoordig bulkt microsoft van de tools en apps, dat hadden we toen nog niet echt. Met behulp van deze tool en onze vastberadenheid om het te laten slagen maakten we een groeispurt naar volwassenheid. Dit alles is alleen mogelijk met draagvlak. Draagvlak moet je hebben binnen het team maar zeker van het management. Dit hadden we zonder meer. We kregen de tijd om dit soort dingen aan te pakken en eigen te maken. Binnen een jaar was het bijna een tweede natuur. Snel schakelen, je tijd verdelen over meerdere projecten zonder overzicht te verliezen, studenten die werden toegevoegd aan het team en ga zo maar verder. Inmiddels een geoliede machine! De organisatie zelf fungeerde op een waterval methode.
In het kort:
Watervalprojectmethodologie is een model waarin elke fase van de levenscyclus van een product achtereenvolgens plaatsvindt. De voortgang stroomt gestaag naar beneden door deze fasen als een waterval.
Agile softwareontwikkelingsmethodologie is het model dat een sequentiële, lineaire en iteratieve benadering voorstelt. Elke oplevering is een werkbaar functioneel stukje software wat meteen toepasbaar is.
Ik ga verder niet te veel uitweiden over hoe en wat wie en waar tussen de twee methodes.
Het internet dwarrelt van de onderzoeken welke nu beter is, hoeveel procent er nu faalt, wordt opgegeven en wat ook succesvol is. Je hoeft niet lang te zoeken dat de Agile vorm betere resultaten oplevert. Wat ik zelf mee heb gemaakt is dat een Agile vorm heel goed fungeert binnen een organisatie. Het nadeel van Agile, even Scrum genomen, is dat we het einddoel kennen. Maar de weg ernaar toe en de tussen opleveringen nog niet helemaal bekend zijn wat tijdens een sprint wel bekend wordt. Bij een waterval wordt alvorens bekend gemaakt wat we gaan opleveren. Dus de eindklant denkt te weten wat hij kan verwachten. Even een pragmatisch voorbeeld:
Case:
Een klant wil software voor een besturing van een hydraulische cilinder. Aansturing is met een proportionele klep. De minimale eis is een positie gestuurde regeling.
Waterval:
Sales verkoopt het, oplevering over 8 weken. Op basis van inschatting van vorige verkochte projecten minimaal 20% (want we wilden graag het project) is er een prijs afgeschoten. De klant is tevreden en bereidt dit ervoor te betalen. De Sales is overigens niet helemaal stom en zet in het contract een clausule dat meer werk op basis van nacalculatie gerekend wordt. Iedereen start het project. Met de vage aanbieding en geen duidelijke requirements begint de automation engineer druk op het toetsenbord te rammelen om de code in elkaar te hacken. Nu blijkt al snel dat de uren verstookt zijn, maar dat de software nog zeker niet precies draaiende is. Van alles een beetje. Na wat interne meetings met Sales en projectmanagement wordt er besloten om de software als volgt op te leveren: De klep wordt gestuurd door de software totdat de cilinder op de gewenste positie is. Geen regeling als meer een start-stop systeem. Dit is nog haalbaar binnen budget. Na oplevering blijkt dus dat de klant niet bedoelde wat er is opgeleverd. Er moet nog een S-ramping functie in komen waarbij er op snelheid en positie geregeld kan worden. Standaard PID met wat feedforward. Uiteindelijk wordt de prijs bijna verdubbeld en is de opleverdatum 4 weken vertraagd.
Agile:
Er wordt 1 sprint van 4 weken aangeboden aan de klant. Niet meer niet minder. Na deze 4 weken wordt er al wel een werkbaar stukje software opgeleverd. Het doel van deze sprint is een goede software opzet, inlezen van alle inputs, schrijven van de outputs en op basis van overulle de cilinder in en uit kunnen sturen. Haalbaar volgens de automation engineer. Aan het einde van de 4 weken is de Sprint Review. De stakeholders zijn hier aanwezig en zien dus wat er wordt opgeleverd. Op basis van deze informatie wordt er besloten om nog een sprint van 4 weken uit te voeren. Tijdens deze sprint review geeft de klant zijn wensen en eisen op aan het scrum team. Het is dan aan het scrum team om te bepalen welke ze gaan implementeren. Na twee sprints blijkt het systeem aan de wensen en eisen te voldoen van de klant. Dus oplevering in 8 weken.
Oplossing
Nu liggen beiden behoorlijk genuanceerd natuurlijk. Ik schrijf met de pen naar Agile toe, maar de situatie is niet onwerkelijk. Het voordeel bij waterval is dat de klant denkt te weten wat hij gaat krijgen. Het nadeel is dat met te weinig communicatie vaak niet hetgeen wordt opgeleverd wat verwacht werd. Dus tijdens software engineering is het vaak wenselijk om de klant zo nu en dan erbij te betrekken.
Het nadeel van de Scrum is dat ‘niemand’ betaalt voor een sprint van 4 weken om vervolgens maar te hopen dat er iets werkend opgeleverd wordt. Want de klant weet ook wel dat er in 4 weken geen werkende machine is. Hoeveel sprints moeten er dan nog komen? Hoeveel geld gaat dat allemaal wel niet kosten voordat we klaar zijn? Precies! Iemand vertrouwen op zijn blauwe ogen doen we ook nog steeds niet.
Wat werkt dan wel?
Ik denk niet dat er binnen de Industriële Automatisering een heilige graal is. Belangrijk is wel dat wanneer er gekozen wordt voor één methode, er draagvlak is binnen het team. Op zijn minst 80% van het team. De andere 20% wil vaak nog wel volgen als ze zien dat het werkt. Persoonlijk ben ik ook wel voor een ‘mix and match’. Het is mogelijk om de waterval methode en Agile methode te combineren. Dit pasten wij al toe in de tijd van ALE-Heavylift, bij de control systems binnen de R&D afdeling. Ik ervoer dit als een prettige werkmethode. Het bracht een stukje structuur en rust binnen het control system team. Het is natuurlijk ook een utopie om een hele organisatie van de een op de andere dag om te gooien van waterval naar Agile. En dan verwachten dat dit vlekkeloos verloopt.
Sales verkoopt het project met een x aantal eisen voor een x bedrag. De eisen kunnen verder worden uitgewerkt volgens de MoSCoW-methode. Must haves – Should haves – Could haves – Won’t haves. Deze worden in de sprints meegenomen. Het aantal sprints is bekend door de opleverdatum en het budget. Je itereert naar werkbare stukjes code in het project. Dit werkt ook mooi als de eisen van de klant aan het begin nog niet helemaal helder zijn of de klant wil nog de mogelijkheid houden om nieuwe technologie in te bouwen. Los van welke methode je precies toepast, is het belangrijk om een goede software documentatie te hebben alvorens start van het code kloppen. Op basis van een duidelijk eisenpakket is het mogelijk om met beide methoden te kunnen werken.
Wil je in basis meer weten over projectmanagement methodes? Ik vond het boekje “Wegwijzer voor methoden bij projectmanagement” een handig boekje om te lezen. 200 pagina’s groot, waar een tiental methodes in basis aan bod komen en daarnaast wat meningen en verhalen van personen uit het bedrijfsleven.
