Voor de meeste organisatie is het opstellen van een Programma van Eisen geen sinecure. Het is niet alleen veel werk om je eisen tot in detail uit te schrijven, maar ook lastig om geen eisen over het hoofd te zien. De meeste systemen hebben verschillende groepen stakeholders met allemaal andere eisen en belangen. Het is een hele klus om die stakeholders op één lijn te krijgen en zo een Programma van Eisen op te leveren waar iedereen achter kan staan.
Voor de opdrachtnemer is een Programma van Eisen lastig te doorgronden. Hij heeft doorgaans onvoldoende kennis van het businessdomein om de eisen in context te plaatsen. De ervaring leert verder dat een Programma van Eisen zelden consistent, ondubbelzinnig en specifiek genoeg is.
Het is niet verwonderlijk dat de bekende schommelkarikatuur nog steeds zo herkenbaar is. Deze karikatuur brengt de problemen treffend in beeld.
Drie fundamentele problemen
De afgelopen decennia zijn er veel best practices en methoden en technieken ontwikkeld om de resultaten te verbeteren. We moeten echter constateren dat dit slechts een marginaal effect heeft gehad. Volgens mij komt dat omdat we de echte problemen niet aanpakken. Ik zie de volgende fundamentele problemen:
- De gebruikers weten vooraf nog niet precies wat voor systeem ze nodig hebben
Het is vrijwel onmogelijk om op voorhand alle ins en outs van de nieuwe situatie te overzien. Tot in detail aangeven wat je eisen en wensen zijn voor een systeem dat de nieuwe situatie gaat ondersteunen, is onbegonnen werk. Mensen hebben daar een concreet beeld van de nieuwe situatie voor nodig. Het is een bekend verschijnsel dat zodra het nieuwe systeem is ingevoerd de gebruikers precies kunnen aangeven wat ze eigenlijk hadden willen hebben. De uitdrukking 'I know it when I see it' komt daar vandaan. - Een Programma van Eisen is moeilijk te doorgronden
Voor de betrokkenen aan zowel de opdrachtgevers- als de opdrachtnemerszijde is een Programma van Eisen lastig te doorgronden. Dit komt omdat het een omvangrijk document is met veel details. Hierdoor zien mensen door de bomen het bos niet meer en krijgen ze geen concreet beeld van de gewenste werking van het systeem. - Interpretatieverschillen komen pas bij oplevering aan het licht
Bij communicatie tussen mensen zijn misverstanden en interpretatieverschillen nauwelijks te voorkomen. Ook voor schriftelijke communicatie geldt immers dat er altijd ruis op de lijn zit tussen zender en ontvanger. Toch gaan we ervan uit dat de opdrachtnemer een systeem oplevert dat voldoet aan het Programma van Eisen. De onvermijdelijke verschillen tussen de behoeften van de opdrachtgevende organisatie en de interpretatie van de opdrachtnemer worden pas bij oplevering duidelijk.
Een echte oplossing
Zolang we deze problemen niet aanpakken blijft de schommelkarikatuur actueel. Zelfs met nieuwe best practices zijn er dan geen grote verbeteringen te verwachten. Voor een echte oplossing is een vernieuwende aanpak nodig. Een aanpak die het huidige patroon doorbreekt zodat we niet meer hoeven te vechten tegen de problemen uit de schommelkarikatuur.
Reacties
Volgens mij zijn de 3 aangegeven fundamentele problemen prima te ondervangen:
"Een Programma van Eisen is moeilijk te doorgronden". Zorg voor een beperkte omvang of deel het systeem op in segmenten. (kort samengevat)
Voor de andere 2 funcamentele problemen is bijv. Agile een prima methode om dit te ondervangen. Sneller resulaten en meer betrokkenheid van de business in het traject zorgt er voor dat veranderingen in wensen en bedoelde functionaliteit eerder aan het licht komen en opgevangen kunnen worden.
De klassieke watervalmethode kan ook, maar dan is het in dit soort trajecten alsnog aan te raden om met deelopleveringen te werken.
Te vaak sluit men zich op in een DoKa om na een aantal maanden eruit te komen en te ontdekken dat de wereld er toch anders uitziet dan gedacht.
Los hiervan is goede, heldere en tijdige communicatie/rapportage ontzettend belangrijk in dergelijke trajecten. Helaas schort het hier nog wel eens aan.
Herkenbaar en wat er bij komt is dat er vaak veel eisen worden gedefinieerd die niet over het aan te schaffen product/dienst gaan, maar over bijvoorbeeld omzet/solvabiliteit van de leverancier.
Enerzijds begrijpelijk, je zoekt continiteit, maar toch een momentopname. Niemand die dit naderhand monitort.
Ik vergelijk het altijd maar met het kopen van een TV. Dan denk je ook niet na over de solvabiliteit van de winkelier.
Het mooiste is eigenlijk (maar dat schijnt niet te mogen) dat je (bij een keuze voor software) gewoon eerst bepaalt welk pakket je hebben wilt en dan een aanbesteding schrijft voor de leverancier die het pakket met leveren en implementeren
Nico's opmerking "Te vaak sluit men zich op in een DoKa om na een aantal maanden eruit te komen en te ontdekken dat de wereld er toch anders uitziet dan gedacht" is in mijn ogen één van de grootste oorzaken van de beschreven problematiek.
Ik heb al heel veel architecten zien komen en gaan, die wel even zouden vertellen hoe e.e.a. er uit zou moeten zien en zou moeten werken. Dit alles het liefst van uit een academische en ivoren toren.
Vooral in complexe omgevingen, waar hardware, electronica, mechanica en software samen komen, en realtime gedrag heel belangrijk is, willen theorie en praktijk nog wel eens uiteenlopen.
Die mooie dynamische netwerk infrastructuur blijkt in theorie, en zelfs in praktijk te werken. Echter, door alle netwerkcomponenten die gebruikt zijn, gecombineerd met de technische hoogstandjes die de componenten afzonderlijk allemaal ten toon spreiden, blijkt de netwerk latency het systeemgedrag behoorlijk negatief te beïnvloeden. Die oude, handmatig te configureren opzet, was dan misschien niet zo "sexy", maar wel retesnel.
En met die nieuwste technologiën kun je prachtige GUI's maken, maar als die vervolgens zoveel systeemresources claimen dat de systeem-performance er onder lijdt, dan is het dus onbruikbaar in een real-time omgeving
Papier is theorie zijn geduldig, de praktijk doorgaans veel weerbarstiger.
In plaats van zichzelf opsluiten in de donkere kamertjes, kunnen betreffende architecten veel beter eens gaan meelopen op de werkvloer, met hun voeten in de modder staan en/of tot hun ellebogen in de smeerolie.
Dan pas leren ze hoe de apparaten echt gebruikt worden, en leren ze denken vanuit de praktijk i.p.v. achter de tekentafel.
De schommel illustreert het probleem inderdaad perfect. Als je erop clickt, zie je pas dat het eigenlijk wat groter had moeten zijn, zodat je het ook echt kan lezen, zegmaar.
Toch ben ik het met Nico eens dat er voor de 3 fundamentele problemen wel degelijk een oplossing is : Agile/Scrum/Sprint.
Lever snel iets op dat de opdrachtgever aan het denken zet, waar die echt behoefte aan heeft. In iteraties doe je opleveringen die het eindproduct steeds dichter doen aansluiten bij de klantwensen.
Zo voorkom je dat alleen een Drs Requirements Specialist nog weet wat er nou eigenlijk gevraagd werd.
Klantwensen kunnen overigens best veranderen naarmate het project vordert. Een wiskundig computerprogramma voor een nucleaire deeltjes versneller zal zich waarschijnlijk inderdaad wat minder voor Agile lenen. Maar daar zijn vast ook iets minder specificatie problemen.
Er wordt voor ingewikkelde projecten al enige tijd de methodiek van Prestatieinkoop gebruikt. Komt er in het kort op neer dat de aanbestedende partij zijn rol verandert: van expert naar het herkennen van de expert.
De methodiek gaat er dus van uit dat de leverancier de expert is. In het selectietraject krijgt de leverancier ook alle ruimte om aan te tonen dat hij de expert is. Niet door middel van het beantwoorden van een uitgebreid programma van eisen, want iedereen kan 'ja' schrijven op alle eisen en wensen. Nee, bij prestatieinkoop geeft de leverancier zijn visie op het project en benoemd alle risico's en beheersmaatregelen die hij ziet. De performers onderscheiden zich zo vrij eenvoudig van de non-performers.
Rijkswaterstaat en de belastingdienst maken al regelmatig gebruik van deze vorm van aanbesteden. Interessante kost.
Het is niet open deuren intrappen. Zelf heb ik destijds een methodiek ontwikkeld (Hebben nl. als eerst 1990 in de Benelux erp en global solution mogen introduceren). Bij deze introductie bleef dat onze sdm methodiek niet meer toepasbaar was, maar wij knipten het in drie delen op; Verkenning, Selectie en Implementatie. Omdat in die periode maatwerksoftware zich als product eigenschappen transformeren, betekent dat definieren van eisen-pakket al modellerend via RFI tot CRP met stellig zekerheid kom vastellen aan de hand van eerdere geimplementeerde bedrijven. De methodiek hebben vervat in SIS (ofwel susccesbol Implementeren). Werd eerst voor onze consultants gehanteerd daarna aan eindgebrikers die opzoek zijn naar een nieuw systeem. De bestaande modellen zijn gericht naar diverse branches; Het moddeleren geeft die garantie van functionaliteiten, immers die draaien al. Het verbaasd mij anno 2013 dit artikel te moeten lezen, zie publicatie in 1999 met de kop "houd de regie in eigen hand" en stappenplan etc.....
Zie mijn publicatie januari 1999 http://www.computable.nl/artikel/achtergrond/erp/1429571/1276992/stappenplan-voor-succesvol-selectie-en-implementatieproject.html, waar de 16 stappen van de methodiek zijn beschreven; Betekent dat de opdrachtgever een TOOL in handen heeft om tot een succesvolle implementatie te komen; wij hebben maar 400 implementaties gedaan Global en waren de trenzetten van erp etc.. etc...
Herkenbaar en waar artikel. Zo niet voor 'inkopers' bij de overheid. Die blijven denken dat je complexe systemen simpelweg aan kunt besteden door "gewoon op te schrijven wat je wilt". Resultaat: lage kwaliteit, dure systemen, mislukte projecten. Reactie: volgende keer moeten we het beter van tevoren opschrijven. Neerwaartse spiraal, verkwisting van belastinggeld. Het wordt tijd dat we (ze) weer eens na gaan denken.
Volgens mij zijn er twee nog belangrijker problemen:
1- Er wordt onvoldoende gecommuniceerd en
2- Er wordt onvoldoende gemanaged op betere communicatie
De drie in dit stuk benoemde problemen zijn het gevolg. Daarvan wil ik graag het volgende zeggen:
Dat gebruikers vooraf niet weten wat voor systeem ze nodig hebben klopt. Dat horen gebruikers ook niet te weten. Gebruikers horen wel te weten wat voor functionaliteit ze nodig hebben.
Een PvE is moeilijk te doorgronden. In dat geval is het tijd voor plaatjes. Vroeger werd vaak gebruik gemaakt van een globaal ontwerp waarbij de gewenste functionaliteit grafisch werd weergegeven, al dan niet in uitgewerkte ontwerpen van schermen, soms al “werkend”. Die werden eerst aan gebruikers getoond. Een wat arbeidsintensiever traject, maar lonend omdat de gebruiker op voorhand ziet wat hij gaat krijgen en er nog nauwelijks sprake is van voortschrijdend inzicht als het te laat is.
Interpretatieverschillen komen pas later aan het licht. Klopt en je legt al uit dat dit het "onvermijdelijke" gevolg is van slechte of onvoldoende communicatie. Dat is dus het echte probleem, zoals ik hiervoor al aangaf.
Om te zorgen voor goede communicatie tussen business en IT is de inmiddels op de markt gebrachte FSM methode een mogelijk hulpmiddel. FSM vult het gat tussen opdrachtgever en opdrachtnemer zoals ze in dit stuk genoemd worden. Dat gat is zonder goed werkende processen en afspraken in de functioneel beheer/ informatiekolom vrijwel onoverbrugbaar.
Nicole,
dat is een heel herkenbare beschrijving van de in mijn praktijk vaak optredende problemen.
Oplossing(kje) : zo vroeg mogelijk een prototype van de UI, en die met eindgebruikers doornemen. Dat werkt bij de opdrachtgever heel verhelderend, en daaruit volgt een convergentie van wensen (en mogelijkheden binnen tijd en geld) ten aanzien van de functionaliteit; globaal een combinatie van RAD en Prince2.
De hele technische kant (datamodel, database, programmeertaal etc) wordt in een zoveel mogelijk apart traject met de technici afgewikkeld.
Toon zo veel en zo vaak mogelijk je voortgang en ook tussenresultaten ("kijk, hoe lijkt jou dit?","B. zou zus willen maar hoe sta jij daar tegenover ?"), juist buiten het formele projectoverleg.
Randvoorwaarde is dat je bij de opdrachtgever in huis zit, en het is allemaal waanzinnig veel overleg maar het levert soms zelfs blije klanten op.
Lastige materie, en ik kijk uit naar jouw ervaringen en ideeën over de aanpak.
Ik zou nog een stap verder willen gaan dan de meeste hierboven aangeven.
In mijn ogen zijn de problemen alleen (echt) oplosbaar als we bereid zijn om een PvE met alle gedetailleerde eisen daarin los te laten. Als de opdrachtgever en -nemer gaan samenwerken en er veel ruimte is om bij te sturen (feedback op schermprototypen of beter op werkende software na iedere sprint) is een PvE ofwel dichtgetimmerd contract niet meer nodig.
Belangrijke punten:
- vervang schriftelijk communicatie zo veel mogelijk door mondelinge communicatie.
- Vervang het vooraf opstellen van eisen/wensen gedeeltelijk door het geven van feedback op prototypen en reeds ontwikkelde software.
- Probeer het niet in één keer perfect te doen (opstellen eisen/wensen en bouwen gewenste software), maar laat het geleidelijk groeien o.b.v. voortschrijdend inzicht. Voorwaarde is eenvoudig onderhoudbare code (pas daarvoor de moderne technische practices toe).
Als ter zake kundig, PM in enkele van dit soort projecten, heb ik in het midden mogen staan van deze twee snijvakken. Ik heb hierbij twee ervaringen.
Het communicatie gat
Tussen IT en Non IT zit een gat. Ik zie maar heel weinig mensen, in Nederland dan, dat gat werkelijk kunnen dichten, tussen IT en non- IT. Dat is namelijk heel basaal Het Probleem. Telkens weer. Als je namelijk als IT, Non - IT niet kan overbrengen wat IT is, hoe het als materie werkt, dan krijg je dit soort grotere en kleinere situaties.
Dan krijg je dus dat je opdrachtgevers hebt die maar roepen.... 'Doe mij maar....' en IT, die denkt ... Ik mee te hebben gehoord dat zij 'Zoiets' willen.
Het is werkelijk niet zo moeilijk. Wat ik nu eigenlijk nog steeds niet begrijp, is dat veel IT professionals cracks zijn in hun discipline, maar dat zij klaarblijkelijk nog steeds niet in staat zijn, Non-IT helder te maken wat en hoe IT is en zich gedraagt, en hoe je ermee om moet gaan, naar Non-IT toe.
Natuurlijk weet ik wel hoe dat komt. Maar het is werkelijk tijd dat het gewoon zo even wordt benoemd. Dit is namelijk de basis van het probleem. De sleutel hiervoor is...... maak je klant inzichtelijk wat IT is, hoe je ermee om moet gaan en waarom. Zorg dat je de wetmatigheden ook zelf kent, en je bespaart.
Want laten we wel zijn mijn beste professional. IT is een prachtige vehicle dat besparingen moet bewerkstelligen. Niet enorm veel moet kosten, zoals nu zo vaak het geval is.
Hoi Nicole,
over die interpretatieverschillen wil ik nog wel iets zeggen. Om te voorkomen dat deze pas achteraf zichtbaar worden, wat je natuurlijk nooit helemaal voorkomt, zou je ten tijde van het opstellen natuurlijk diverse requirements kunnen voorleggen aan diverse stakeholders afzonderlijk en hen vragen hun interpretatie te geven. Als je dan al behoorlijke verschillen waarneemt in die interpretaties zou je vóór indiening van het PvE al de requirements kunnen aanscherpen.
NumoQuest heeft helemaal gelijk dat er een gat zit tussen IT en non-IT. Voor de opdrachtgever is IT niet zijn kernactiviteit, daarom roept hij ook de hulp in van een IT bedrijf. Van zo'n opdrachtgever moet je niet willen verwachten dat hij de IT eisen goed kan benoemen. Dat is niet zijn kracht. Die ligt bij de IT.
Daarom geloof ik ook, samen met onder andere Joost, in de kracht van prestatieinkoop (ook wel BVP = Best Value Procurement). De opdrachtgever geeft aan WAT hij nodig heeft en wat hij er voor over heeft om dat op te lossen. Dat gaat over zijn kernactiviteiten en zijn bedrijfsvoering. Vervolgens geeft de IT leverancier aan HOE dat het beste opgelost kan worden binnen de financiële kaders. Dat is het vak van de leverancier.
IT moet dus leren denken in termen van de klant. Dat zal hier en daar wel even wennen zijn, maar gaat beide partijen een hoop plezier opleveren. De opdrachtgever krijgt IT oplossingen die zijn probleem oplossen binnen gestelde financiële kaders en de IT'er krijgt de ruimte om vanuit zijn vak oplossingen te bedenken voor echte problemen van zijn klanten.