Reading Bernie Grinyer’s account of the challenges of managing client expectations last week certainly rang true.
Why it is that any major technical development requires so much ‘discovery’ and ‘technical analysis’ – yet still does not guarantee the right outcome, or any outcome at all?
Your consultant is an expert! This is their career! How come they don’t know what to do?
Well, sometimes the simple problems aren’t that simple…
Consider the following situation:
- You’re a wine drinker.
- You’ve only ever seen wine bottles with screw caps.
- You’re given a corked bottle of wine but you don’t know how to open it.
So you go your bottle-opening consultant, you give them the bottle and a simple brief:
‘Here, open this.’
Solution Design & Development
A person who’s opened a wine bottle before will find a corkscrew and open the bottle in under a minute. They’d most likely ask if you want a glass of wine, find a glass and serve.
Another person may have seen someone de-cork a bottle before; they would be able to work out how to do it and find the tools required. They’d probably also ask if you want a glass. They’d take a bit longer to complete the action, but it would be the right outcome.
Those without the benefit of these insights might seek out those with more experience than them – asking the advice of a barman or someone with a passion for wine. It’s going to take a while to get your glass of wine!
Alternatively, they might fall back on their own experience opening other bottles, google bottle opening techniques or find a book on how to open wine. Others still might try an unconventional approach – after all, the brief was to open the bottle, right? No mention of what condition the contents or bottle need to be in?
The Best Outcome vs. The Brief
When we look at the ‘perfect’ solution to the corked bottle o’ wine conundrum, it requires three components:
- a tool (corkscrew)
- a user who can to deploy this tool
- expertise on how to deploy the tool in a way that will solve the customer’s problem
In many ways this reflects development. In order to achieve the perfect outcome the first time, a consultant needs to know the right tools to use, how to use the tools and how to apply the tools to a specific purpose.
Sometimes this is easy. If it’s an area of expertise or something your consultant has done before, they’ll know exactly which steps to carry out to achieve the outcome you desire.
Even if these components are not available it is not the end of the world:
- The consultant can fall back on previous experience;
- They can work with others who’ve had experience solving similar problems;
- They can crowdsource a solution – your specific requirement might not have been solved before but others may have done something similar
However, this takes time – and effort – to work through. If they’re working in an iterative development environment (where the solution is built at the same time that it is developed) they may also be doing development as they work out how to achieve your specification.
No two solutions are completely alike and throughout the course of development there are frequently limitations that your consultant has to somehow work into the solution.
This is where the brief becomes particularly important. A tight brief minimises wasted effort exploring solutions which may not fit purpose.
Ambiguity = Cost and Complexity
In the wine example, the brief is very ambiguous. “Here, open this” doesn’t specify what condition the wine needs to be after extraction. Neither does it specify the tools that need to be used, what needs to happen to the wine after it’s been extracted or the expected outcome is. Nearly any solution will achieve the brief – but does not meet the underlying requirement!
In the same way, a loose brief can lead to unexpected consequences down the track. If a consultant knows the restrictions and limitations of the project, they can work within those limitations.
When Bernie and the team estimate how long it will take to achieve an outcome they will do so based off what the client has told them.
They’ll invest a certain amount of time and effort in understanding the requirement and designing a solution but they will work to the set of criteria and assumptions that the client has already made.
Preparing the Best Outcome
To help your consultant prepare for the best outcome, you need to:
- Ensure you have covered over as much detail as possible in the brief
- Clearly state your assumptions
- Clearly state the tools and processes which may be used
- Clearly explain what the end outcome is that you desire (you do not need to worry about how this outcome is achieved unless there are specific midpoints you need to meet)
- Create ‘success’ and ‘failure’ scenarios which can be used for testing
- Be a part of the review process
Under these conditions, as a wine drinker you should have:
- Explained to the bottle opener what you want to occur
- State what you have assumed – ‘I will need to be able to drink the wine that is in the bottle’
- State the tools and processes which may be used: ‘You could use a corkscrew to open the wine’
- State the outcome you require: ‘I’d like to drink some wine’
- Create success and failure scenarios: ‘Once the bottle is open, I should be able to drink this wine’
- Check in frequently on the project to ensure it’s on track
That’s it! Now, where’s that corkscrew?