Als engineer heb je te maken met verschillende klanten met ieder hun eigen behoeftes, eisen en wensen. Voor ieder probleem wordt een oplossing gezocht en de manier van communiceren verschilt vaak per klant en per case. In een eerdere post hebben we vijf skills benoemd die iedere engineer moet bezitten om ieder probleem te tackelen. Hier gaan we dieper in op de technische specificaties. Hoe ver moeten deze worden uitgewerkt en wat kun je doen als de aangeleverde eisen en specificaties niet voldoen?

Het verschil tussen behoeften, voorkeuren en oplossingen

De ene klant is een stuk specifieker dan de ander. De één weet al precies wat hij wil en de ander heeft slechts een globaal idee van wat hij nodig heeft. De manier waarop dit gecommuniceerd wordt richting engineers is grofweg te verdelen in behoeften, voorkeuren en oplossingen. Om dit te illustreren gebruiken we een restaurant als voorbeeld. Klanten kunnen van alles zeggen tegen de ober, onderstaand drie uitspraken. Welke van de drie is een behoefte? En welke een oplossing?

• "Ik lust wel wat te eten"
• "Ik zou graag een pizza bestellen"
• "Ik zou graag een pizza prosciutto bestellen"

De eerste uitspraak is duidelijk een behoefte, de klant wil wat te eten en specificeert verder niets. De tweede is een voorkeur hoe de behoefte ingevuld moet worden. De klant heeft honger en wil dat oplossen met een pizza, maar welke? De laatste uitspraak is een duidelijke oplossing, de klant heeft honger en weet al precies welk gerecht dit probleem moet gaan verhelpen. Voor de ober vraagt iedere uitspraak om een andere aanpak. Een goede ober is getraind om iedere situatie goed aan te pakken en de juiste vragen te stellen, dan wel de juiste oplossing te bieden. In de eerste situatie kan hij nog alle kanten op en zou hij de klant kunnen ‘uitdagen’ om iets nieuws of onbekends te proberen, waar de laatste situatie weinig ruimte meer biedt voor interpretatie.

Als professional in de technische wereld zul je deze situaties waarschijnlijk ook vaak tegenkomen. De ene klant levert al heel specifieke wensen en eisen aan, terwijl de ander alleen globaal het probleem beschrijft. Je wil de klant natuurlijk bieden waar hij om vraagt, maar zoals we in de vorige blog al beschreven is het niet altijd de beste oplossing om dit klakkeloos over te nemen. Probeer daarom de specificaties te ontleden naar behoeften, voorkeuren en oplossingen om erachter te komen wat daadwerkelijk de beste oplossing is.

Klanten praten liever over oplossingen dan over behoeften

Hoe vaak heb jij in een restaurant tegen de ober gezegd: “ik lust wel wat te eten, verras me maar”? Het merendeel van de mensen zal een specifiek gerecht willen bestellen. Hetzelfde principe zien we ook terug in de technische wereld van engineers. De volgende redenen zijn hier deels de oorzaak van:

• Klanten denken dat ze op die manier een betere inschatting van de kosten kunnen maken
• Een soortgelijke oplossing is al eerder gebruikt
• De klant is niet op de hoogte van alternatieve oplossingen
• Nieuwe/andere ideeën worden gezien als risico ten opzichte van bekende ideeën
• De persoon of personen die de specificaties opstellen zijn niet getraind om onderliggende behoeften te omschrijven

Wanneer is het goed om een kant-en-klare oplossing te vragen?

Wanneer je een leverancier instrueert moet je goed nadenken over de gevolgen. Een zeer gedetailleerde briefing is vaak vooraf gegaan door een langdurig proces. Je hebt alle behoeften duidelijk op een rijtje, hebt de verschillende opties bekeken en de oplossing geselecteerd die het beste bij jouw probleem past. In deze situatie kun je niet meer aan een leverancier vragen om te voldoen aan je oorspronkelijk behoefte, omdat je zelf al het risico hebt genomen om het grootste gedeelte van de oplossing ‘uit te tekenen’. De leverancier hoeft eigenlijk alleen nog maar te bouwen wat jij voorschrijft en zal contractueel gezien dus ook minder risico hoeven te lopen wanneer deze oplossing toch niet de juiste blijkt te zijn. Dit is namelijk jouw keuze geweest waar zij geen invloed meer op konden uitoefenen. Het vragen om een kant-en-klare oplossing kan goed zijn in de volgende situaties:

• Het vervangen van onderdelen in een systeem dat al draaiende is
• De stakeholders zijn al naar hun mening gevraagd en vinden de oplossing aanvaardbaar
• Er is al een prototype dat uitgebreid getest en goedgekeurd is

Inperken van specificaties

Wanneer je als leverancier gedetailleerde specificaties krijgt kan het soms goed zijn om deze toch wat in te perken. Het is belangrijk om de specificaties goed uit te pluizen en op zoek te gaan naar belangrijke zaken waar de behoefte van de klant in schuilt. Soms beschrijft de klant een aantal beperkingen of voorwaarden die eigenlijk helemaal niet nodig zijn. Deze dienen van tevoren te worden besproken en eventueel te worden geschrapt uit de specificaties. Een aantal voorbeelden:

Denken vanuit de standaard

‘Het voertuig moet vier wielen hebben’. Deze eis is gedacht vanuit een geldende standaard, maar waarom is dit noodzakelijk? Misschien kan er wel een betere oplossing geleverd worden met twee wielen, of een vliegend voertuig?

Denken vanuit fysieke structuren

Vaak heeft de klant al een idee van de oplossing en ziet hij dit ook al voor zich. Dit beeld werkt vaak door in de eisen. Vaak is dit te zien aan het woordje ‘wanneer’. Bijvoorbeeld: ‘wanneer de bestuurder zijn locatie op wil vragen licht het display op en toont het GPS-systeem de huidige locatie’. Hierbij gaat de klant al uit van een display met GPS-systeem voor het bepalen van locatie, maar is dit de enige oplossing voor het bepalen van locatie?

Een beperking bevat geen beargumentering

Binnen een briefing met technische specificaties zijn vaak vele beperkingen aanwezig, denk bijvoorbeeld aan de vier wielen uit bovenstaand voorbeeld. Er zijn allerlei redenen te bedenken waarom deze eis op papier staat, maar zolang deze beargumentering er niet bij wordt vermeld is het zaak om hier altijd naar te vragen. Zijn de argumenten niet toereikend? Vraag je dan af of de beperking moet worden geschrapt.