Iedereen is een requirements engineer

Transcriptie

1 Iedereen is een requirements engineer In 2009 bestaat Synergio tien jaar. Tien jaar minder gedoe en meer inspiratie. Typisch een moment om ons te bezinnen op wat we bereikt hebben. Maar ook voor een vooruitblik. Als we terugkijken, wat is dan eigenlijk de essentie van wat we die duizenden mensen hebben verteld tijdens de trainingen? Wat zouden we willen dat ze hebben geleerd van de coaching momenten? En naar de toekomst? Wat is eigenlijk onze belangrijkste boodschap aan organisaties die met requirements willen gaan werken of er al mee werken? Het antwoord op de laatste vraag staat eigenlijk al in de titel. Iedereen is namelijk een requirements engineer. Hiermee zeggen we eigenlijk dat we niet meer geloven in een aantal gangbare manieren om een organisatie in te richten. Tenminste als het gaat om het werken met requirements. Zo geloven we niet meer in een afzonderlijke functie requirements engineer zoals je die vaak in organisaties en ook in boeken tegenkomt. En ook niet meer in een vakgebied Requirements Engineering of Requirements Management zoals het vaak wordt genoemd. We laten ons niet meer leiden door boeken en methoden die het werken met requirements beschouwen als iets dat op zichzelf staat met eigen processen en werkwijzen. Integendeel! Eindresultaat Laten we beginnen uit te leggen waar we wél in geloven. Ons vertrekpunt is dat het werken met requirements een generieke vaardigheid is. Namelijk de vaardigheid om niet direct in activiteiten of oplossingen te denken maar vooral goed stil te staan bij het beoogde eindresultaat; de werkelijke behoeften. Dus, om in meer bedrijfskundige termen te spreken, datgene wat het waard maakt om ergens in te investeren. Wij geloven dat organisaties pas echt goed kunnen presteren als ze bij elke investering (vaak ook verandering, programma of project genoemd) een helder antwoord kunnen geven op de vraag: Wat willen we ermee bereiken?. En waarom een generieke vaardigheid? Generiek omdat het een vaardigheid is die iedereen in een organisatie ontzettend kan helpen om effectief te zijn. Dus ook de directie, ook managers, ook projectleiders, ook uitvoerenden op de werkvloer; iedereen. En misschien niet alleen tijdens het werk, maar zelfs in je privéleven. Helder doel Bij Synergio noemen we deze visie het begin bij het eind paradigma. Aan begin bij het eind ligt een aantal zienswijzen ten grondslag. Eén van de zienswijzen is wat Stephen Covey beschrijft in zijn boek The seven habits of highly effective people. Daarin beschrijft hij zeven principes die de basis vormen voor het gedrag van mensen die op een prettige manier (dus zonder al te veel gedoe) veel weten te bereiken, zakelijk en privé. Begin bij het eind is eigenlijk een praktische manier om invulling te geven aan een aantal van die principes. Met name het tweede principe. Covey noemde dat: begin met het eindresultaat helder voor ogen. Dit principe maakt dat mensen weten wat ze willen bereiken. Vanuit die basis doen ze de juiste dingen en zetten ze de juiste oplossingen in. Het begin bij het eind -paradigma is in essentie een fantastische aanvulling op de gangbare manier van plannen en sturen. In de volgende twee paragrafen lichten we dat kort toe.

2 Requirements als plan-instrument Er zijn in de loop der tijd verschillende manieren bedacht om te plannen. De twee meest gangbare manieren zijn productgerichten activiteitgericht plannen. Productgericht Bij deze manier van plannen zijn de op te leveren producten het vertrekpunt. We noemen die producten ook wel deliverables Het gaat dan om de vraag wat er allemaal moet worden opgeleverd, wanneer, in welke volgorde en door wie. Los van de vraag hoe deze producten kunnen worden opgeleverd. Aan de basis van een productplanning staat de product breakdown structure, vaak afgekort tot PBS. De PBS geeft de opdeling weer van hoofdproducten in kleinere deelproducten. Activiteitgericht Hier gaat het erom hoe de producten uit de PBS kunnen worden opgeleverd. Centraal staat dus het uit te voeren werk, de activiteit. Bij activiteitgericht plannen gaat het om de vraag wat eerst en wat later gedaan moet worden, door wie, met welke doorlooptijd en voor welke prijs. Aan een activiteitenplanning ligt een work breakdownstructure ten grondslag, vaak afgekort tot WBS. De WBS is een opdeling van hoofdactiviteiten in kleinere deelactiviteiten. Resultaatgericht Met het begin bij het eind -paradigma voegen we hier een derde manier van plannen aan toe; resultaatgericht plannen. Bij resultaatgericht plannen staat het waarom van een investering centraal. Een resultaatplanning beschrijft twee dingen: 1) bekwaamheid (Eng.: capability): dat wat er na de beoogde investering beter gaat (bijv. voor de klant of voor de medewerker) 2) bate (Eng.: benefit): wanneer (na de investering) welke waarde/verzilvering merkbaar is Stel: een organisatie stelt de klanten in staat om ongeacht plaats en tijd een bestelling te plaatsen. Dan zien de bekwaamheden in het resultatenplan er mogelijk als volgt uit: De klant kan <overal> een bestelling plaatsen. De klant kan <op elk moment van de dag>een bestelling plaatsen. Het plaatsen van een bestelling kan <eenvoudig>. De bijbehorende baten zouden er dan zo uit kunnen zien: <Meer> verkopen <Hogere> klanttevredenheid Tussen de tekens < en > staan begrippen die verder uitgewerkt moeten worden omdat ze nog onvoldoende specifiek zijn (de s van SMART). Zo kun je de begrippen meer en hogere kwantificeren (uitdrukken in een getal en een eenheid). Ook moet je de bekwaamheden prioriteren. Niet alles hoeft direct bereikt te worden en niet alles is even belangrijk. Praktisch Het gaat te ver om in dit artikel uit te leggen hoe je een resultaatplanning maakt. In ons boekje Begin bij het eind, met SMART requirements zetten we alle belangrijke informatie aan de hand van praktische richtlijnen voor je op een rij. Geen dikke pil dus, maar een handzaam boekje waarmee je al heel snel perfecte requirements kunt schrijven (zie Een resultaatplanning bestaat uit een boomstructuur van requirements. Elk requirement verwoordt in één heldere, bondige zin een beoogd eindresultaat. Een dergelijke boomstructuur wordt ook wel result breakdown structure genoemd, afgekort tot RBS. We hebben dus te maken met drie manieren van plannen met alle drie een eigen blik op de wereld: - resultaatplanning (RBS): o welke bekwaamheden willen we verbeteren? o wanneer is de verbetering in de tijd merkbaar? o wat leveren deze verbeterde bekwaamheden op (baten)? - productplanning (PBS): o welke oplossing is wanneer in de tijd leverbaar? o welke grondstoffen en basiscomponenten zijn nodig en wat kosten ze? - activiteitplanning (WBS): o welke activiteit moet wie wanneer uitvoeren zodat de oplossing tijdig is te leveren? o wat kost het om de activiteiten uit te (laten) voeren?

3 De volgende afbeelding geeft deze drie planningsvormen grafisch weer. Invloeden Belangrijk is dat de planningsvormen elkaar aanvullen. Alleen als duidelijk is welke bekwaamheden beter moeten (m.a.w. wat het beoogde eindresultaat is) kun je oplossingen bedenken om je doel te bereiken. Een productplanning is dan een handige weergave van de oplossingen die je op bepaalde momenten in de tijd nodig hebt. En alleen met de productplanning als kapstok weet je welke activiteiten nodig zijn om de oplossingen te maken/leveren. activiteiten lang duren. Dan heeft dit een negatief effect op de levertijd van een product. Als een product een lange levertijd heeft, heeft dat een negatief effect op het tijdig kunnen verbeteren van een bekwaamheid. Daardoor merk je de invloed van bepaalde baten later dan gewenst. Een andere situatie die veel voorkomt, is dat een deel van het product niet maakbaar blijkt te zijn. Het blijkt toch complexer dan in eerste instantie werd ingeschat. Dan kan je een deel van de bekwaamheden niet verbeteren omdat de oplossing hiervoor ontbreekt. Het niet kunnen verbeteren van bepaalde bekwaamheden leidt tot een vermindering van baten. Misschien komt hierdoor de hele investering wel onder druk te staan. Bestuurbare investeringen Kortom, met het begin bij het eind -paradigma heeft een organisatie een essentieel planningsinstrument in handen. Essentieel, omdat met een activiteitenplanning en een productenplanning alleen de kosten inzichtelijk zijn. Met een resultaatplanning worden ook de baten inzichtelijk. Daarmee zijn investeringstrajecten bestuurbaar te maken op basis van een juiste kosten/baten verhouding. Planningen vullen elkaar niet alleen aan, ze beïnvloeden elkaar ook. Stel dat bepaalde Requirements als stuurinstrument Begin bij het eind is zeker niet alleen een manier van plannen. Het hebben van een resultaatplanning is natuurlijk al mooi, maar de kunst is om het plan slim te gebruiken. Alleen dán bereik je daadwerkelijk wat in het plan staat. Dus moet het plan bruikbaar zijn om mee te sturen. Met het begrip sturen bedoelen we dat een organisatie het proces om iets te bereiken, in zekere mate in de hand heeft. Sturen betekent dan beheerst van richting veranderen. Alles om het werkelijke resultaat zo dicht mogelijk bij het beoogde resultaat uit te laten komen. Dr. Demming heeft dit perfect uitgelegd aan de hand van de PDCA cyclus; een acroniem voor de Engelse werkwoorden plan, do, check en act (ook wel adjust genoemd).

4 Gelijktijdig In het kort komt deze cyclus er op neer dat sturen bestaat uit vier activiteiten: plannen, uitvoeren, meten en reageren/bijstellen. Deze activiteiten volgen elkaar niet zozeer op, maar vinden continu en nagenoeg gelijktijdig plaats. Het aspect act is dan het werkelijke (bij)sturen. Wat maakt begin bij het eind dan een stuurinstrument? Dat zit hem in de levenscyclus van elke stelling. Elke stelling in het resultatenplan doorloopt gedurende zijn bestaan, een aantal keren de volgende stappen: De eerste stap noemen we behoefte. In deze stap beschrijft de stelling alleen nog het ideale resultaat. Met andere woorden, wat willen we als er geen beperkingen bestaan. Dit is de wens van de opdrachtgever. Die praat in eerste instantie met een opdrachtnemer in termen van wat zou ik het liefst willen bereiken?. Voor een bekwaamheid ziet de behoefte er bijvoorbeeld zo uit: De klant kan <op elk moment van de dag> een bestelling plaatsen. 24 uur per dag, 7 dagen in de week En de baten zo: <Meer>verkopen + 25% <Hogere>klanttevredenheid + 10% Plan De tweede stap is het afgesproken resultaat. Deze ontstaat doordat een opdrachtnemer moet onderzoeken in welke mate de wens van de opdrachtgever haalbaar is. Dit noemen we vaak een haalbaarheidsanalyse. De opdrachtnemer, bijvoorbeeld een project, houdt dan rekening met de beperkingen die de opdrachtgever meegeeft. Denk daarbij in termen van tijd en geld. Het resultaat van de tweede stap in de levenscyclus is dus een afspraak tussen opdrachtgever en opdrachtnemer. In de afspraak houd je rekening met de mate waarin de behoefte (naar verwachting) is te realiseren binnen de opgelegde beperkingen (tijd en geld). Voor een bekwaamheid zou het afgesproken resultaat er zo uit kunnen zien: De klant kan <op elk moment van de dag> een bestelling plaatsen. 24 uur per dag, 7 dagen in de week 22 uur per dag, van maandag t/m zaterdag En de baten zo: <Meer> verkopen + 25% + 20% <Hogere> klanttevredenheid + 10% + 10% Een goede resultaatplanning geeft zowel de behoefte weer als het afgesproken resultaat. Daardoor is inzichtelijk wat de consequenties zijn van de opgelegde beperkingen en beschikbare capaciteit (middelen). Deze stappen zijn in de PDCA cyclus onderdeel van de activiteit plan. Check In de derde stap ontstaat het geobserveerde resultaat door te meten (observeren) of het afgesproken resultaat daadwerkelijk wordt waargemaakt.

5 Voor een bekwaamheid ziet het geobserveerde resultaat er mogelijk zo uit: De klant kan <op elk moment van de dag> een bestelling plaatsen. 24 uur per dag, 7 dagen in de week 22 uur per dag, van maandag t/m zaterdag 19 uur per dag, zaterdags tot uur, niet op feestdagen En de baten zo: <Meer> verkopen + 25% + 20% + 10% <Hogere> klanttevredenheid + 10% + 10% + 5% In de PDCA cyclus zorgt de activiteit check voor het geobserveerde resultaat. De opdrachtgever meet steeds tijdig en houdt nauwgezet het verschil in de gaten tussen het afgesproken resultaat en het geobserveerde resultaat.. Minder gedoe, meer energie Zo kan de opdrachtgever volgen of hij/zij krijgt wat was afgesproken. En zo niet, dan kan hij/zij tijdig ingrijpen (bijsturen). Dit maakt begin bij het eind een krachtig instrument om grip te krijgen op het eindresultaat en niet te laat (of achteraf pas) te constateren wat het werkelijke resultaat is Wat bereikt een organisatie nu met het toepassen van begin bij het eind? Begin bij het eind heeft als resultaat dat mensen en afdelingen beter met elkaar samenwerken. Véél beter zelfs, omdat er minder gedoe ontstaat. Want de belangrijkste oorzaak van gedoe is dat mensen elkaar onvoldoende begrijpen. Dat gebeurt vaak zonder dat ze het zelf in de gaten hebben. Omdat er meters gemaakt moeten worden gaat men haastig aan de slag zonder dat het vertrekpunt voor iedereen even duidelijk is. Met als gevolg dat alsnog veel tijd verloren gaat aan discussies om erachter te komen wát er bereikt moet worden. In kleine kring worden dan gesprekken gevoerd en de uitkomst zit alleen in de hoofden van die mensen en is daardoor niet snel te delen. Vooral als grote groepen mensen (vanaf zeven) met elkaar moeten samenwerken of als mensen niet continu bij elkaar zitten, leidt dit tot een gigantische hoeveelheid communicatietijd en momenten. En niet te vergeten: veel verspilde energie. Goed opdrachtgeverschap Het resultaat van begin bij het eind kan nóg specifieker. Zo is het dé manier om het opdrachtgeverschap te verbeteren. Een goede opdrachtgever is glashelder in het te bereiken eindresultaat en houdt continu een vinger aan de pols om tijdig bij te kunnen sturen. De onderdelen van begin bij het eind zorgen ervoor dat opdrachtgevers eenvoudig toe te passen instrumenten hebben om het eindresultaat te beschrijven. En dat in een vorm die zelfs makkelijk meetbaar te maken is. Meer ondernemerschap Ook zorgt begin bij het eind voor meer ondernemerschap in een organisatie. Typerend aan ondernemerschap is het slim en optimaal inzetten van de beperkte middelen. Een goede ondernemer staart zich niet blind op één idee maar heeft de grote lijnen goed voor ogen en wil steeds de beste oplossing uit de beschikbare alternatieven kiezen. Een goede ondernemer weegt risico s en besluit daadkrachtig. En om zo min mogelijk middelen te verspillen, is het belangrijk dat hij/zij zo snel mogelijk weet of een investering voldoende waarde toevoegt. Om in het negatieve geval een investering zo vroeg mogelijk te stoppen.

6 Succesvol implementeren Hoe kun je als organisatie het best het werken met requirements implementeren? Laten we kort stilstaan bij de twee meest voorkomende valkuilen. Valkuil 1: requirements als methodiek Wat in de meeste gevallen niet werkt, is om het werken met requirements als een geheel nieuwe methodiek te introduceren. In dat geval ontstaat vaak het zoveelste nieuwe handboek. De methodiek wordt beschreven als iets dat op zichzelf staat. Met te weinig aandacht voor de integratie van disciplines waardoor projectleden uiteindelijk juist slechter samenwerken. Mensen met te beperkte ervaring in het toepassen van requirements schrijven dan een methode. Ze willen de methodiek specifiek maken voor de organisatie want bij ons werken we anders. Hierdoor raakt de essentie uit beeld en gaat veel tijd verloren. Het momentum verdwijnt. Het resultaat is een handboek dat nagenoeg niemand leest, laat staan dat het wordt toegepast. Valkuil 2: requirements als specialisme Wat ook heel beperkend werkt, is om mensen aan te stellen als specialist op het gebied van requirements. Specialisten participeren dan bijvoorbeeld in projecten en zijn verantwoordelijk voor het uiteindelijk succesvol opleveren en het gebruik van requirements. Onder druk van het project ontstaat een groot gevaar: alle energie gaat zitten in het tijdig opleveren van de requirements. Daardoor besteedt men nauwelijks aandacht aan het creëren van begrip en acceptatie bij de mensen die uiteindelijk met de requirements moeten gaan werken (zoals opdrachtgevers, stuurgroepleden, projectmanagers en projectleden). Ook hebben specialisten in de organisatie vaak niet het mandaat om opdrachtgevers, stuurgroepleden en projectmanagers te begeleiden en indien nodig aan te spreken. Tot slot is het voor deze mensen moeilijk om de juiste requirements te schrijven. Doordat ze zelf geen ervaring hebben in de rol van opdrachtgever, stuurgroeplid of projectmanager hebben ze een ander wereldbeeld. Dus hebben ze vaak een te beperkt beeld van hoe de doelgroep de requirements in de praktijk kan gebruiken. Succesvol implementeren Om het werken met requirements succesvol te implementeren, helpt het om ze te zien als een vaardigheid. Een vaardigheid die grofweg bestaat uit: - het beoogde eindresultaat vaststellen en helder formuleren; - het beoogde eindresultaat inspirerend overbrengen op anderen; - met belangstelling observeren of wat er gedaan wordt in lijn is met het beoogde eindresultaat en zo niet, tijdig bijsturen. Het is de kunst om in een organisatie die functies en processen te selecteren die het meest gebaat zijn bij het verbeteren van deze vaardigheid. De meeste organisaties staan immers al bol van de functies en processen. Vaak is met requirements de meeste winst te behalen bij de volgende processen (in willekeurige volgorde): - visieontwikkeling - programmaen projectmanagement - productmanagement, -ontwikkeling en marketing - acceptatiemanagement en testen (validatie en verificatie) - beheer en exploitatiemanagement - servicemanagement

7 Is dus iedereen een requirements engineer? Het antwoord op deze vraag is zowel ja als nee. Ja, omdat volgens ons de meerderheid van de functies en processen in een organisatie ontzettend gebaat zijn bij de vaardigheid om te beginnen bij het eind. Hierbij moet dan wel het motto gelden: goed is goed genoeg. Het werken met requirements is geen doel op zich. Niet iedereen hoeft daarin even goed te zijn. Niet overal in de organisatie hoeft het even gedegen te worden aangepakt. Maar het is wel essentieel dat iedereen de essentie begrijpt en ervaart hoe prettig het is om met minder gedoe samen te werken. En het is ook prettig als er niet alleen requirements zijn, maar als ze daadwerkelijk gebruikt worden. Kortom, als iedereen vaardig is om vanuit zijn eigen specialisme de requirements slim te gebruiken. Maar het antwoord op deze vraag is ook nee. Nee, omdat het werken met requirements weinig zin heeft als het beperkt wordt geïmplementeerd. Bijvoorbeeld door de verantwoordelijkheid voor requirements te beleggen bij specifieke functionarissen zoals requirements engineers, requirements beheerders, requirements managers, business analisten of welke naam ze dan ook hebben. En dit laatste is ook helemaal niet nodig. Uiteindelijk is het werken met requirements eenvoudig te leren. De technieken zijn niet moeilijker dan lezen, schrijven, praten of rekenen. Pas als requirements het domein worden van goeroes en academici dreigt het bijna een kunst te worden. Eén die dan nog maar door weinigen effectief is toe te passen. Met begin bij het eind hebben we het werken met requirements voor iedereen begrijpbaar en praktisch toepasbaar gemaakt. Geïnteresseerd? Neem dan gerust geheel vrijblijvend contact met ons op. En natuurlijk is ons boekje begin bij het eind met SMART requirements een perfecte manier om een goed beeld te krijgen van het werken met requirements als vaardigheid. Te bestellen via Tot slot wensen we iedereen minder gedoe en meer inspiratie toe. Wellicht tot gauw! Synergio B.V.