Onlangs botste ik met een mok thee tegen een collega aan. De oorzaak was een onoverzichtelijke hoek, waardoor we elkaar te laat zagen. Geen van ons had bedacht dat er wel degelijk iemand zou lopen, ook al konden we die niet zien. Kahneman legt in zijn boek ‘Thinking, fast and slow’ uit waarom mensen niet in staat zijn rekening te houden met de mogelijkheid dat ze iets niet weten. Dat klinkt als een open deur, maar is daarom niet minder waar.
De aanname dat onze kennis volledig is en dat er niet meer te weten valt dan we weten, is vaak een grote hindernis in pakketselecties. In vrijwel elk offerte-verzoek zie ik eisen en wensen die letterlijk de detail-eigenschappen van het vorige systeem beschrijven: ‘het systeem moet widgets hebben’, ‘de message queue van het systeem moet kunnen worden gemanipuleerd’, ‘er moet een OTAP-straat bestaan voor de content’. In veel gevallen begrijpen we de omschrijving van de eis niet eens, laat staan dat we een bevredigende reactie kunnen formuleren.
Het is best logisch natuurlijk: degene die de eisen heeft opgesteld, kent natuurlijk vooral het systeem waar men afscheid van wil nemen. Geheel automatisch (want onvermijdelijk) wordt de aanname gedaan dat het nieuwe systeem ongeveer hetzelfde in elkaar zal zitten en dat de zaken die in de oude situatie normaal waren, ook in de nieuwe situatie normaal zullen zijn. Een andere wetmatigheid werkt hier ook nog flink mee: de menselijke geest heeft meestal aan één voorbeeld genoeg om hele complexe systemen te snappen: ‘Seen one, seen them all.’
De slagingskans van selecties kan heel eenvoudig worden vergroot: beschrijf niet wat het systeem moet doen, maar beschrijf wat u ermee wilt bereiken. Dat doet u als volgt. U bedenkt bij elke beschreven eis, waarom het voor u een eis is. Streep vervolgens de eis door en vervang hem door het waarom. Zo beschrijft u niet de handelingen van de gebruiker, maar het resultaat daarvan. U beschrijft niet de kenmerken van de tool, maar van het doel. U zult verrast zijn dat er systemen zijn die hetzelfde voor u kunnen bereiken, maar dan sneller, goedkoper en handiger. En u zult wellicht ook verrast zijn dat er ineens veel meer systemen door de selectie komen. En vooral: u zult verrast zijn dat er systemen zijn die allerlei dingen voor u kunnen betekenen, waar u nog nooit aan gedacht had.
Goed stuk, nu maar hopen dat veel klanten dit ook gaan lezen. De vraag is niet “hoe”, maar wat hij bereikt en onder welke voorwaarde.
Ik deel Ron’s mening van harte. Specifieke (design) details van een nieuw systeem opnemen in een bestek heeft alleen zin als je er absoluut zeker van bent dat dat de ‘best practise’ implementatie is van het functionele doel. Tenzij je een echte specialist bent, kun je dat dus beter niet doen. Wat Ron voorstelt, ligt in het verlengde van ‘Best Value Procurement’. Dat zou m.i. de standaard moeten zijn bij selectie/inkoop van complexe ICT-oplossingen. Zeker niet zelf het wiel uitvinden met weinig bruikbare detailbestekken.
@Jaap : Ondanks dat er wel wat in reactie zit voel ik een allergie reflex om hoe je het formuleert. Alleen al het woord “Best” van “Best practices”. Hoe weet je dat iets het beste gebruik is?
On-topic : Het begin van je opinie vind ik maar matig, het einde erg interessant omdat je dat ook terug ziet in software: Imperative versus declarative.
Tenminste, dat lees ik hieruit:
“Zo beschrijft u niet de handelingen van de gebruiker, maar het resultaat daarvan.”
Declaratieve code is meestal behoorlijk omdenken. Volgens mij breekt iedereen zijn nek er in het begin over totdat het begint de dagen.
Imperatief is vertellen tegen de computer wat hij moet doen; de handelingen.
Declaratief is definiëren wat het resultaat is en de onderliggende laag realiseert dit voor je.
Dit werkt in mijn ogen niet alleen goed in software en gewenste software beschrijvingen, maar ook in het aansturen van mensen. Niet vertellen wanneer ze wat moeten doen, maar welke resultaat je wilt en wanneer je dat resultaat nodig hebt. Geheid succesvoller.
Maar vooral de laatste alinea maakt dat ik de opinie sterk vind 🙂
Resumerend zegt Ron, ‘specificaties bestaan uit het opsommen van wat moderne modegrillen’. What else is new?
Ron,
Even een andere dementie van je verhaal:
Je bent op zoek naar een systeem. Volgens jouw artikel ga je:
– niet de handelingen maar het resultaat beschrijven,
– niet de kenmerken van de auto maar van het doel,
En kortom meer de functionaliteiten dan eigenschappen.
Iemand komt met een bekend merk X (dus duurder in aanschaf) en ik kom met een onbekend merk Y…..(voordeliger in aanschaf)
Maar ze doen exact hetzelfde. Hoe ga je gebaseerd op deze zaken mijn offerte beoordelen?
1- Je weet wat je al hebt, je bestaande merk X heeft zich al 5 jaar bewezen. Maar je weet niet wat je krijgt (het onbekend merk Y)
Durf je dit toch aan te schaffen voor de komende 5 jaar?
2- Je leveranciers in de keten ondersteunen je huidige merk. Wat ga je doen als ze geen support kunnen geven op je nieuwe onbekende merk?
3- Je beheerorganisatie kent het product al dus minder onderhoudskosten dan wanneer je externe mensen door gebrek aan kennis van het nieuwe merk moet inhuren (verborgen kosten),
4- Je krijgt nu ook support bij andere organisaties dan alleen je huisleverancier. Bij het onbekende merk ben je afhankelijk van ene leverancier waar het inhuren van een consultant 135 euro p/u kost.
En……. nog meer andere punten.
Nu ben ik benieuwd, durf je gebaseerd op dezelfde functionaliteit een investering voor de komende 5 jaar doen in een onbekend product?
Durf je in de komende 5 jaar je business en de hieraan gerelateerde zaken op dit product bouwen als je niet zeker bent van de supportorganisatie, kwaliteit van dienstverlening, kosten etc.?
Of ga je kiezen voor de veilige optie…….sturen op eigenschappen van wat je al hebt en dan misschien weer terugkomen in de “productgroep’ van je initiële product?
@Reza:
Met de aanpak van Ron rollen er bekende en onbekende merken/producten uit. Eventueel gekoppeld aan werkwijzes waar je wellicht nog nooit aan gedacht had.
Van hieruit kan je keuzes maken. Als angst hierin leidend is kies je voor de bestaande olifanten paadjes.
Als een balans tussen risico’s en resultaten (vernieuwing/innovatie?) leidend zijn maak je vrijwel zeker andere keuzes.
Kortom – aspecten die langskomen bij het runnen van een bedrijf (ondernemer zijn).
Waar ik nou benieuwd naar ben is het antwoord op de vraag “wat zou jij kiezen?”. Zeker gezien de “andere dementie”… 😉
@Pascal: al gaat mijn artikel er juist helemaal niet over, ben ik wel met je eens dat de specs in een RFP vaak een opsomming zijn van de laatste modegrillen en hypes. Dus: dank hiervoor, je reactie is op z’n minst inspirerend voor een volgend blogje.
@Reza en @Will: mijn Blog gaat specifiek in op de situatie dat men wel degelijk op zoek is naar iets nieuws. Je hebt gelijk dat aanbestedingen vaak als hinderlijk ervaren worden omdat men eigenlijk best tevreden is met het huidige product, maar het nu eenmaal weer tijd is geworden om aan te besteden. Maar nog steeds is het verstandig om de eisen dan zo te omschrijven dat je ook oplossingen ontdekt die je nog nooit had gezien.
@Jaap de Jonge: Je schrijft “Wat Ron voorstelt, ligt in het verlengde van ‘Best Value Procurement”. Ik zou bijna zeggen: “betrapt…” want BVP vormde inderdaad de inspiratiebron voor dit stukje. Waarmee ik overigens niet wil zeggen dat ik kritiekloos fan ben van BVP, maar dat ene aspect is erg waardevol.
Deze blog lijkt over ICT te gaan maar is van toepassing op elke klantrelatie in zowat elke markt!