How can mediation thinking help with evaluating commercial business problems?
When asked the question: “…so what does a Business Analyst really do?”, my nut shell answer, after 20 years in the role, is to state that a BA acts as a “translator” between business stakeholders and software developers. The full evaluation of why one might need a ‘translator’ between two stakeholder groups who theoretically speak the same language is the subject of another article below, but one of the reason’s is that BA’s technical knowledge of the core business systems is usually far more detailed than that of operational business stakeholders. It has taken me quite a while to appreciate that knowing more about how an organisation’s systems work does not necessarily mean that I know more about how to solve the business operational problems than the operational stakeholders do.
One of the defining principles of mediation is that the disputing participants know more about how to solve the problems between them than anyone else does. Which is why any mediation agreement will only work in the real world if it has been generated by the participants themselves and not handed to them by a third party.
The more experienced I became as BA, the easier it was fall into the trap of assuming that I knew what system changes would best solve a business stakeholder’s problem before I had fully listened to whole business issue. Sometimes this prevented me from fully exploring the range of issues and business interests that lay underneath the stated business problem. It also led to ‘solutioning’ too early, for both myself and for the respective business stakeholders.
To avoid this premature solutioning type thinking, I continually remind myself of three defining principles within the mediation problem resolution framework:
Focus on interests not positions.
Use “open questions” to get to underlying interests.
Be humble and assume that the person with the problem knows more about how to solve it than you do.
It could be argued that when a business stakeholder approaches a development team with a suggested system change, in doing so they are ‘taking a position’. There are risks in approaching any problem with a set outcome or position in mind, not the least of which is that you are likely to engender a reaction of opposing positions being immediately presented as a defence against change being introduced without being evaluated fully, (for example, developers in the development team saying “No, the system can not sustain that type of change”). Hence I have found it is really important to dig into the interests underlying the solution that the business stakeholder is proposing, rather than immediately confront this solution with an alternative one. Our brains generally find it easier to think about ‘what we need’ before we think about ‘why we need it’, and so it is a natural tendency for stakeholders to come to the party with a suggested solution rather than a clear explanation of the business problem they are trying to solve. As I have developed more knowledge of systems over the course of my career, I have found that it takes more conscious effort to stay focused on talking about the interests of the business when a problem is presented, and not to either immediately side with, or immediately oppose, the position/solution that is being proposed by a business stakeholder.
It may seem simple, on the face of it, to focus on interests rather than positions, but I would contend that the more experienced you are as a problem solver within the business the more conscious you have to be of not landing on a solution too early. Exposing the full range of underlying interests for any business problem means asking a lot of open ended questions. Don’t worry, the more questions you ask the more your stakeholders will appreciate that you really want to help them solve the problem, and in the process they will feel like they are being more actively listened to rather than striking the same old brick walls of inherent system development resistance. As a side benefit of exposing underlying interests, it is generally far easier to get software developers aligned with suggested system change when they can understand the ‘why’ behind the request.
So next time your presented with a business problem to solve, think about applying some mediation method to your approach and see how it goes.