Systems Engineering

Het is wellicht in dit tijdperk van agile ontwikkeling vloeken in de kerk, maar deze blog gaat over systems engineering. Systems engineering stond ooit model voor de inmiddels veelal verguisde watervalmethoden, zoals de Systems Development Methodology (SDM) I en II. Ook projectmanagementmethodes als Prince2 vinden hun oorsprong in systems engineering.

  • 04-06-2018
  • Blog

Waarde bewezen

Systems engineering heeft z’n waarde bewezen en wordt in steeds verfijndere toepassingen gebruikt in GWW-projecten en is ook goed toepasbaar in complexe ICT-projecten en programma’s. Agile ontwikkelingen binnen het raamwerk van systems engineering zijn ook goed mogelijk.

Het is niet de intentie hier een uitvoerige beschrijving te geven van systems engineering. Daar is meer dan voldoende materiaal over voorhanden. Ik wil volstaan met een paar zinnen uit Wikipedia, zodat het onderwerp in ieder geval eenduidig is:

“An interdisciplinary field of engineering and engineering management that focuses on how to design and manage complex systems over their life cycles. At its core, systems engineering utilizes systems thinking principles to organize this body of knowledge. Systems engineering deals with work-processes, optimization methods, and risk management tools in such projects.”

Je kunt systems engineering op verschillende manieren vormgeven. In de organisatie waar ik projecten heb uitgevoerd was sprake van een watervalmodel, met een strakke fasering en een V-model zoals we dat ook in TMap tegenkomen.

In dit artikel focus ik me op het traject van de projectopdracht tot en met het komen tot een Design & Construct contract met een opdrachtnemer (in het algemeen een aannemerscombinatie).

Design en Construct contract

Een Design en Construct contract is precies wat de naam zegt: de eisen worden vooral functioneel gespecificeerd door de opdrachtgever. De opdrachtnemer verwerkt dit in een Design en voert de realisatie (Construct) uit. In de constructfase, voert de opdrachtnemer diverse tests uit, de Functionele Applicatie Test (FAT) en de Software Applicatie Test (SAT), waarna de opdrachtgever het acceptatietraject uitvoert, middels fysieke afnames ter plekke, de Integrated Site Acceptance Test (ISAT) en Gebruikers Acceptatie Test (GAT).

Het onderwerp is een complex project, met civiele techniek en een behoorlijke dosis industriële automatisering. De opdrachtnemer is in dergelijke gevallen meestal een combinatie, vanwege de uiteenlopende expertises die noodzakelijk zijn.

De uitvoering (de Design & Construct) en acceptatie raak ik in dit artikel slechts summier. Er zijn voldoende leerpunten te halen uit het voortraject, met een doorkijk naar de uitvoering en acceptatie.

Stappen Design en Construct contract

Van projectopdracht tot en met het opstellen van het D&C contract doorlopen we in hoofdlijnen de volgende stappen:

  1. Structureren van het project
    • Resultaat: project scope en projectplan
  2. Analyseren en vastleggen van de klanteisen
    • Resultaat: klanteisen specificatie (KES)
  3. Ontwerpen en specificeren van het systeem
    • Resultaat: systeemspecificatie (SYS)
  4. Uitwerken contractspecificaties
    • Resultaat: contractspecificaties (CS)

Elke stap bestaat uit een aantal deelstappen.

De stappen 2 t/m 4 staan achter elkaar maar in de praktijk overlappen ze elkaar en er vindt iteratie plaats. Bij het uitwerken van de systeemspecificatie kan bijvoorbeeld blijken dat een klanteis niet praktisch is. Dan wordt teruggegaan naar de betreffende “klant” om de eis waar mogelijk bij te stellen.

De systeemeisen (SYS) zijn opgebouwd vanuit de klanteisen, aangevuld met normen en standaards, ontwerpspecificatie, aanvullende kwaliteitseisen etc. De contracteisen (CS) zijn de eisen zoals ze in het contract met de opdrachtnemer worden vermeld. In het algemeen zijn dit de eisen uit de SYS, aangevuld met specifieke proceseisen, waarin de samenwerking tussen opdrachtgever en opdrachtnemer goed wordt gespecificeerd.

Komen tot leerpunten

Om tot de leerpunten te komen zijn de volgende inhoudelijke zaken nog van belang:

  • Eisen zijn gestructureerd opgebouwd. Eerst worden topeisen vastgelegd en vervolgens de daarvan afgeleide eisen, tot een niveau dat de eisen specifiek en meetbaar zijn
  • Een complex project bevat al snel meer dan 1.000 klanteisen. De eisen betreffen zowel producteisen (waar moet het eindresultaat aan voldoen) als proceseisen (bijvoorbeeld de mate van overlast die de omgeving maximaal bereid is te ondergaan gedurende het project)
  • De eisen worden vastgelegd in een strak gestructureerd systeem. Vaak wordt hiervoor het product Relatics Quote van de Relatics site: ‘Projectmedewerkers kunnen eisen, verificaties, testen, risico’s, taken en alle overige project objecten beheren in een samenhangend netwerk van expliciet beschreven informatie’
  • De eisen zijn, zoals het hoort, de basis voor de verdere ontwerpen, ontwikkelingen, opleidingen, testen en uiteindelijk acceptatie. Elk product dat gedurende het project wordt opgeleverd wordt geverifieerd ten opzichte van de eisen. Aan het eind van het project wordt o.a. een verificatie- en validatieoverzicht opgeleverd, waarop eenvoudig kan worden afgelezen in hoeverre aan alle eisen is voldaan

Mijn leerpunten

Leerpunten die ik heb meegenomen uit de GWW-projecten, waar ik in verschillende rollen bij betrokken ben geweest, zijn:

  1. Door vanaf de start de eisen zo specifiek en meetbaar vast te leggen, zijn ze ook vrij eenvoudig toe te wijzen aan de producten waarin die eisen moeten worden gerealiseerd. Als bijvoorbeeld in een Voorontwerp (VO) een oplossing wordt beschreven waarmee aan een eis wordt voldaan, kan die eis al worden afgetikt en hoeft het daarna in principe niet meer geverifieerd te worden. Het Definitief Ontwerp en vervolgens het Uitvoeringsontwerp en de Realisatie borduren tenslotte voort op het VO. Tijdens de diverse testfasen wordt wel de volledige eisenmatrix weer als basis gebruikt. Maar ook hier geldt: als in een testfase een eis volledig kan worden aangetoond, hoeft deze ook niet meer in een volgende fase opnieuw te worden bewezen.
  2. Door de definitieve KES op senior management niveau te laten aftekenen en als harde basis te blijven hanteren, is de scopescreep minimaal. Elke afwijking zal op hoog niveau moeten worden geaccordeerd en het projectmanagement heeft dan voldoende ruimte om de consequenties van de aanpassingen van de eisen in kaart te brengen. In de praktijk is het aantal scopewijzigingen hierdoor minimaal. Aanpassing van de eisen wordt vaak als meerwerk na afronding van het project tijdens de onderhoudsfase uitgevoerd.
  3. Door het hanteren van een strak gestructureerd systeem waarin de opdrachtgever de eisen weergeeft, ontstaat de mogelijkheid het gebruik van dit systeem over te dragen aan de opdrachtnemer, die daar zijn aanpak verder op kan afstemmen. De opdrachtgever draagt het beheer en onderhoud van dit specificatiesysteem over aan de opdrachtnemer en behoudt zelf leesrechten op het systeem. Op deze wijze kan de opdrachtgever op elk moment inzicht krijgen in hoeverre aan eisen is voldaan en op welke wijze de opdrachtnemer dit heeft geverifieerd. Dit geeft veel inzicht zonder dat het aan de zijde van opdrachtgever en/of opdrachtnemer veel tijd kost.

Mijn ervaring is dat er gedurende het project en bij oplevering relatief weinig discussies zijn of aan de gestelde eisen is voldaan. Waar deze wel ontstaan betreft het vaak onvoldoende nauwkeurig gespecificeerde eisen, vaak ontstaan vanuit verwachtingen die niet voldoende expliciet zijn gemaakt.

Alle projecten waar ik bij betrokken ben geweest en die volgens systems engineering zijn opgestart en uitgevoerd, hebben binnen tijd en budget het afgesproken resultaat bereikt. Nul mislukkingen. En daar doen we het voor.

Profiel Wim Schuurmans

Tientallen jaren heb ik gewerkt als projectmanager op het snijvlak van Business en ICT. Door toeval ben ik nu sinds een jaar of 6 ingezet op project- en contract management van Grond-, Weg- en Waterbouw (GWW) projecten. Hierbij heb ik me positief verbaasd over de professionaliteit van de projectenorganisatie. Een ingebakken professionaliteit. Misschien niet voor iedereen verrassend, maar voor mij toch reden een aantal van die waarnemingen te delen.

Dit artikel maakt deel uit van een serie van in totaal 12 artikelen:

  1. Integrale Project Management Teams
  2. Systeemgerichte Contract Beheersing
  3. Risico Management als leidraad
  4. Deterministische en Probabilistische planning
  5. Project Start-ups en Project Follow-ups
  6. Prestatie Verklaringen
  7. Verificatie en Validatie
  8. Systems Engineering
  9. De duivelsdriehoek, imago en veiligheid
  10. Het belang van software(testen) in tunnels en bruggen
  11. De organisatiematrix
  12. Minder mensen / meer werk
  • Wim Schuurmans

    Senior Project- en Programmamanager

    Een verfrissende aanpak en een optimaal resultaat.

    Meer over Wim Schuurmans

  • Wim Schuurmans

Wil je meer weten?

We vertellen je graag meer over onze aanpak van het succesvol managen van projecten en programma’s.

Bel ons op 030 – 600 47 79 Stuur ons een bericht