Specificeren op (het juiste) niveau

Een nieuwe project! We hebben net een stapel eisen en een kant en klare System Breakdown Structure (SBS) gekregen. We mogen volgens het hippe Systems Engineering aan de slag om te ontwerpen. Joepie!
Opdracht 1 lijkt makkelijk: “koppel de eisen aan objecten”. Mmm… direct is dan de vraag: “aan welk object moet ik die eis dan koppelen? Dit artikel gaat over een ogenschijnlijk simpel probleem, maar is ingewikkelder dan je denkt.

Er spelen bij deze opdracht namelijk verschillende aspecten die ik maar weinig terug zie komen in de verschillende normen, handleidingen en artikelen. In dit artikel een poging om antwoorden te geven. Geef ook jouw ervaring!


Om de problematiek duidelijker te maken, wil ik je eerst vragen om een simpele tafel met vier tafelpoten in gedachten te nemen. De [tafel] kunnen we ontleden in onderdelen (objecten). De onderdelen zijn tafelpoten [A], [B], [C] en [D] en een [tafelblad]. Makkelijk, toch? In dit voorbeeld plaatsen we nog wel een ‘groeperingsobject’ tussen de [tafel] en de afzonderlijke tafelpoten, namelijk [tafelpoten]. De objectenboom kent hiermee dus drie niveau’s.

Eerst een voorbeeld wanneer het koppelen niet moeilijk is… Stel, er is maar één eis aan de tafel: “Het tafelblad moet grijs zijn”. In dat geval is het een eitje. Er is maar één tafelblad, en de eis heeft geen gevolgen voor de overige objecten, zoals de tafelpoten, of de tafel als geheel. Het plaatje ziet er dan als volgt uit:

SBS_eis_tafelblad

Maar wat moeten we doen als de eis is: “Alle objecten moeten grijs zijn”? In dat geval zijn er verschillende oplossingen mogelijk.

Optie 1: de eis wordt gekoppeld aan alle laagste niveau-objecten van de SBS, dat zijn in dit voorbeeld vijf koppelingen en dit er als volgt uit:

SBS_eis_koppeling1

Optie 2: Deze eis kan ook aan het systeem als geheel gekoppeld worden, de tafel. Optie twee heeft een heel ander uiterlijk, met slechts 1 koppeling:

SBS_eis_koppeling2

De keuzemogelijkheid doet zich met name voor als de eis op meerdere objecten betrekking heeft en deze ook op verschillende niveau’s betrekking kunnen hebben. Groeperingsobjecten maken de keus daarbij niet makkelijker…

Waarom is dit een probleem?

Je kunt je op dit ogenblik afvragen: “jeetje, wat maakt die kerel zich druk, wat een lang onzinnig theoretisch artikel. Doe IETS en ga door met je leven!” Dat begrijp ik volledig. Maar… Ik besteed uiteraard niet zo veel tijd aan dit onderwerp als het iets totaal onzinnigs zou zijn. Bovenstaand probleem is uiteraard versimpeld en in daadwerkelijke projecten heb ik inmiddels al verschillende dagdelen met deze vraag geworsteld met diverse deskundigen. De gemaakte keus heeft namelijk daadwerkelijk gevolgen voor diverse rapportages en activiteiten! Voorbeelden zijn:

  • Medewerkers of onderaannemers zien mogelijke objecteisen die voor hem van toepassing zijn helemaal niet en maakt dus iets dat niet aan alle eisen voldoet. Dat kost geld en tijd, en het was nu juist de bedoeling om tijd en geld te besparen.
  • De klant is niet tevreden omdat het geleverde product te weinig controleerbaar is aan de eisen.
  • Bepaalde overzichten die in een latere fase nodig zijn, zijn simpelweg niet te produceren, omdat de benodigde koppelingen niet aanwezig zijn. Iedere koppeling komt immers terug in verschillende rapporten: de objectspecificatie, verificatieplan, verificatierapport, ontwerpnota en afhankelijk van je organisatiebehoefte in andere rapportages, zoals ‘actielijst per persoon’, een Plan van Aanpak, Keuringsformulier, etc.
  • Medewerkers hebben zó veel werk dat de administratie alle tijd opslokt en iedereen helemaal tureluurs wordt.

Met name het laatste punt is een aandachtspunt voor de verantwoordelijke SE-er, maar ook voor de projectmanager

koppeling

(vanuit financieel oogpunt). Als je namelijk 10 objecten en 10 eisen hebt die op ieder object van toepassing is, dan heb je al 100 koppelingen. Als je het aantal koppelingen weet te beperken, dan scheelt dat veel werk! In het laatste project waar ik aan werkte hadden we meer dan 800 eisen opgegeven gekregen en zelf ongeveer 500 objecten gedefinieerd. Dat zijn theoretisch dus 400.000 mogelijke koppelingen! En dan was het ook nog de bedoeling dat we zelf diverse afgeleide eisen zouden bedenken…

Dé oplossing bestaat niet

Je zult begrijpen dat enige consistentie en beleid wel handig is om bovenstaande problematiek te voorkomen of te beperken. Maar welke aspecten bepalen de oplossing? Naar mijn idee moet je bij jouw ‘koppelbeleid’ je de volgende zaken afvragen:question-mark1a

  1. Waarom maak ik de koppelingen eigenlijk oftewel wat is het doel ervan? Om het ontwerp te controleren of zijn de koppelingen juist het uitgangspunt van het ontwerp? Of ben je juist de eisenspecificatie aan het schrijven als opdrachtgever? Of heb je allerlei doelen?
  2. Voor wie ga ik alle eisen en objecten aan elkaar koppelen? Voor mijzelf, voor een rapportage, voor een opdrachtgever, voor de ontwerper, of allemaal? En wat is/zijn hun behoeftes?
  3. Met welke software werk je? Hoe geavanceerd is de software, welke mogelijkheden biedt die?
  4. Hoe komt het er op papier uit te zien? Is het wel overzichtelijk, kun je ermee werken?
  5. Voor welke activiteiten en rapportages heeft een bepaalde keus op lange termijn gevolgen? Bedenk dat de koppelingen mogelijk gevolgen heeft voor meerdere activiteiten en bijbehorende rapporten, zoals bijvoorbeeld bij het ontwerpen, actielijst, de planning, het verificatieplan en verificatierapport, maar wellicht ook een trade-off matrix, risicodossier, vergunningsaanvraag, etc..
  6. Kun je de medewerkers voldoende meekrijgen in een bepaalde werkwijze? Hoeveel training is er nodig, hoeveel kennis is er al, wat zijn de standaard werkwijzen?
  7. Hoeveel veranderingen in eisen en objecten kun je verwachten? Is het stabiel of is alles nog aan verandering onderhevig?

Het allerbelangrijkst is in ieder geval dat je consistent werkt en als regel neemt dat alles óf zoveel mogelijk hoog in de SBS, óf juist zo laag mogelijk in de SBS dient te koppelen. Bovenstaande vragen worden hieronder verder uitgewerkt.

A) Waarom doe je het?

Als opdrachtgever kun je eisen en objecten aan elkaar koppelen, om te controleren of je wel voor ieder object de juiste eisen hebt geformuleerd en geen conflicterende eisen hebt. In dat geval maakt het wellicht zelfs niet zo veel uit hoe hoog of laag je koppelt, als je maar zelf goed door de verschillende structuren heen blijft kijken.
Als het erom gaat dat je een zo specifiek mogelijk startpunt van je ontwerp wilt maken, dan is het juist handig om de eisen zo laag / specifiek mogelijk in de boom te koppelen. De uitkomst is dan immers dat de ontwerper een kant en klaar lijstje eisen krijgt waarmee hij kan werken.
Als het doel is om zo snel mogelijk een ontwerp te verifiëren, dan wil je de eisen zo hoog mogelijk in de objectenboom koppelen, immers hoe minder koppelingen, hoe minder verificaties, dus hoe sneller je klaar bent.

B) Voor wie doe je het?

Realiseer je goed dat verschillende mensen verschillende belangen hebben. Degene die de ontwerpen maakt vindt het fijn als de eisen zo specifiek mogelijk aan het object zijn gekoppeld, zodat de ontwerper niet de hele eisenspecificatie hoeft te bestuderen. Degene die de verificatie doet en vastlegt heeft juist als belang om zo weinig mogelijk koppelingen te hebben, zodat hij/zij niet zo veel werk heeft. Degene die koppelingen in de database moet maken wil ook graag zo weinig mogelijk koppelingen, zeker als objecten en eisen ook nog eens veranderen.
Het is vervelend als je halverwege je project tot de conclusie moet komen dat de keus die je in het begin hebt gemaakt niet de juiste is voor de gebruiker(s). Dat betekent namelijk dat je allerlei koppelingen (en wellicht ook documenten) moet veranderen! Bij de eerder genoemde aantallen wordt je daar niet blij van!

C) Software

Niet iedere software gaat even handig om met het bovengeschetste probleem. Het is handig als je bij wijze van spreken weinig koppelingen kunt leggen, en tegelijkertijd zou kunnen aangeven hoe diep de koppeling zichtbaar moet zijn. Een soort virtuele koppeling leggen als het ware. Maar niet iedere software is daartoe in staat.

D) Op papier

Ieder document moet een doel hebben. Binnen Systems Engineering vallen de doelstellingen samen te vatten als: aantonen, controleren, uitgangspunt bieden, overzicht geven, traceerbaarheid en analyse. Helaas is het zo dat een beknopt overzicht van eisen en volledige navolgbaarheid en traceerbaarheid elkaar vaak uitsluiten, maar dat je in de loop van je project wel met deze zaken te maken kunt hebben. Als er vooral veel koppelingen gemaakt zijn, dan is het overzicht vaak ver te zoeken, maar de navolgbaarheid, traceerbaarheid en controlemogelijkheid is wellicht groter. Verificatiedocumenten moeten daarbij wat mij betreft ook geen ‘fake’ worden. Als de verificator ziet dat een eis op tien objecten terug komt, zou hij dan daadwerkelijk ieder object nauwkeurig gaan verifiëren? Zou je zelf ook niet de neiging hebben om 1 keer goed te verifiëren en aansluitend 9 keer een snelle krabbel te zetten? Daarmee is de aantoonbaarheid wel beter op papier, maar niet in werkelijkheid.

E) Lange termijn gevolgen

Bedenk ook eens wat het gevolg is van jouw koppelingskeus in de toekomst! Vaak maak je in je project heel veel documenten. Tegelijk kun je de SBS ook koppelen aan de WBS en zullen de gevolgen van je koppelingen dus daadwerkelijk langdurig voortduren. Als je alles op een heel laag niveau koppelt, heb je misschien zo veel werk gecreëerd dat de medewerkers veel langer bezig zijn om de pagina-lange rapportages door te worstelen. Ik heb ook al projecten gezien waarbij er extra medewerkers moesten worden aangenomen voor alle administratie en dat kwam de winst en verliesrekening ook niet ten goede.

Andersom kan het goed mogelijk zijn dat je op een gegeven moment vast loopt omdat je bijvoorbeeld je opleverdossier niet voldoende nauwkeurig kunt produceren. Dan kun je veel administratie opnieuw doen!

Probeer dus al aan het begin van je project een inschatting te maken van alle rapporten die later ook geproduceerd moeten worden, maar waar je nu nog niet mee bezig bent. Tip hierbij is om van achter naar voor te werken. Doel is om betaald te worden, daarvoor moet je rapport Z inleveren, en daarom moet je eerst activiteit Y uitvoeren. Om activiteit Y uit te voeren, is document X noodzakelijk etc. Dit kun je pas doen als je ervaring hebt in verschillende projecten.

F) Mensen

Mensen zijn gewend om op een bepaalde manier te werken. Als hen niet verteld wordt dat er iets veranderd is, dan zal dat mogelijk veel frustratie en zelfs fouten geven. De koppelingen hebben namelijk invloed op de informatie die mensen krijgen. Kijken mensen verder dan hun neus lang is, of kijken ze alleen naar datgene wat hun wordt aangereikt? In dat laatste geval moet je wel alles zo laag mogelijk koppelen, in een ander geval kan het wellicht ook hoger.

Ook is het de vraag in hoeverre jouw klanten (en dat zijn ook mensen…) star of flexibel zijn. Hoe vaak gebeurt het wel niet dat een klant vind dat iets een systeem/topeis is, terwijl het over een specifiek onderdeel gaat. Waar ga je die eis dan aan koppelen? Hoe eigenwijs mag/durf je te zijn?

G) Veranderingen

In een tenderfase is het mijn ervaring dat er nog van alles veranderd. De opdrachtgever veranderd nog allerlei eisen en als opdrachtnemer weet je nog niet wat de oplossing is. Als de objectenboom zich nog langzaam uitbereidt naar diepere niveau’s, dan zul je al gemaakte koppelingen mogelijk weer moeten ontkoppelen en aan de nieuw gemaakte objecten koppelen. Dat is heel veel werk! Tijdens de tenderfase heeft een opdrachtnemer dus een groot belang om alle eisen lekker hoog te koppelen. Zodra er gegund is, dan veranderd er niet zo veel meer en kun je de eisen koppelen aan die objecten waaraan ze bedoeld zijn.

Conclusieexclamation mark

Samengevat zou je kunnen zeggen dat het omwille van kwaliteit het beter is om de eisen zo laag mogelijk in de SBS/objectenboom te koppelen. Maar in de tenderfase van een project, wanneer er veel veranderd en er ook op kosten en personeel wordt gelet , is het wellicht verstandiger om het nog een beetje op hoog niveau te koppelen, aan de wensen van de opdrachtgever te voldoen en niet te lange termijn te denken.

Tja, ‘matchmaking’ is een vak apart, waarbij aan meerdere behoeften gedacht moet worden.

Ervaar je dezelfde discussie? Hoe heb jij dit opgelost? Kun jij jouw beleid omschrijven?

2 thoughts on “Specificeren op (het juiste) niveau

  1. De keuze om ‘hoog’ of ‘laag’ koppelen van objecten wordt soms bepaald door het belang van de initiatiefnemer. Voorbeeld hiervan (als Opdrachtnemer) is het betalingsregime van een contract. Om per tafelpoot afgerekent te willen krijgen zal je de eisen op dat niveau moeten koppelen teneinde aan te tonen dat je aan de verplichtingen hebt voldaan. Tijd houd hier verband mee: betalen op tafelniveau betekent wachten tot alle tafelpoten en het tafelblad af zijn.

Reageer hier op dit artikel!

This site uses Akismet to reduce spam. Learn how your comment data is processed.