Als je de ontwikkeling van een systeem wilt uitbesteden aan een in- of externe softwareleverancier zul je duidelijk moeten maken wat voor systeem je wilt hebben. De meeste organisaties stellen hiervoor een Programma van Eisen op. Met een Programma van Eisen geef je als opdrachtgever aan, aan welke eisen en randvoorwaarden het te ontwikkelen systeem moet voldoen. Dit is gewoonlijk een opsomming van vele tientallen of zelfs honderden requirements.
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.
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.