By John Menzies, Enterprise Architect, Integration & Architecture, Devoteam
January 2019
We live in a world that is so focused on delivery, the destination so to speak. We don’t know what we have around us, point A, and we’re trying to run off to point B. Intellectually we already know we need to understand the problem we’re trying to solve before we try to solve it, but in practice do we really do this? Why is everyone so interested in providing solutions to the point that most people I speak with on a daily basis don’t understand what problem they’re trying to solve? I, too, am guilty of this.
Do we listen?
When we enter into a discovery piece of work, how often have you gone in with an outcome already in mind? How often do you only process the points of a discovery that will support your preconceived idea of what the solution should be (confirmation bias)? When trying to identify a problem we must be prepared to listen completely, change our mind and learn along the way. If you find yourself jumping to the conclusion you’ve stopped listening, you’re not processing.
Play back what you’ve heard
The first few times you do this it’s going to feel a little odd. Paraphrase what you’ve heard. By continually replaying what you’ve heard you will absorb more about the problem. The group you’re working with also gets an opportunity to hear, possibly in another way, the problem presented again. Questions can be asked, and discussion ensues.
By playing back the problem you also get to measure how engaged the group is in understanding and owning the problem. There is nothing surer of failure than driving to a solution where the problem isn’t a) well understood or b) owned. In my years of managing teams of developers I’ve learnt that nothing is more powerful than a team owning a problem. Solutions that are thrust upon people often fail to obtain traction through to resolution. Problems that are properly identified and owned fail to stay unresolved.
Have you engaged your audience?
As a client engaging in a conversation with a consultant, or vendor, I was often sceptical, feeling that the other party had an agenda which often resulted in low value conversations. As a Consultant I struggle to demonstrate that my motives are to help the client, to overcome the perception they already have of my intentions. The genuine starting position of understanding is hard to establish, it seems to be a low trust position. Through building relationships, getting to know the other people in the relationship, these preconceived ideas of what the other party is bringing to the situation you can all get on the same page and move forward together.
Have you found the Root Cause?
A problem can only be solved completely if the root cause is known. There are many different techniques for doing this. One that I’ve found most effective, and at times extremely uncomfortable, is the “5 Whys” developed originally by Sakichi Toyoda and subscribed to by Toyota in their manufacturing plants. Every time someone provides what they believe to be the reason why something is a problem we should then question why that is the problem. Often when doing this you’ll find that the real cause is not the first answer that comes to mind. This approach will fail if the analysts around the table do not have an open mind. Watch out for egos when working through this stage, I’ve found personally that it can be the biggest obstacle to finding the root cause.
Great, you’ve found the Root Cause. What Next?
A solution may present itself very quickly once the root cause is known, but I’d like to provide some quick points to keep in mind when honing the solution to your new root cause:
- Does technology have to play a part in the solution? If the cost of a technology solution is greater than providing a manual work around, then why use technology? This is probably an entirely new post that I may explore later on calculating the true cost;
- Is the root cause a problem with a utility function or a market differentiator? This is a key question because the solution may already be well defined and available out-of-the-box for you. If it’s a market differentiator, make sure you calculate the true value of a technology solution (see point one).
And finally
Don’t be afraid to say that the problem cannot be solved in a cost-effective way. This is another problem I’ve seen time and time again. Program and project managers, stake holders and product owners, architects and developers unable to admit that the solution to the problem simply isn’t viable and can’t be achieved, despite all the best efforts and planning. Sunk costs are hard to swallow, but I believe it is a valuable lesson to learn, and one that may save you in future endeavours to be able to look reasonably at a problem and solution before you invest and properly assess the risk of failure.
Further to this, as solution providers, consultants (not in the commercial sense, but anyone in the process providing a solution) should provide open, transparent options. This will foster trust between parties and result in relationships that last longer and yield higher value results for everyone involved. Providing solution options allows the business to make a decision that will best fit with its strategies as opposed to assumptions being made about what may be best for either party.