Creative problem solving is kind of my thing - I've been doing it my entire career - and I have a reputation for quickly understanding thorny issues and coming up with innovative approaches to break out of the cycles that created them.
As a freelance consultant, one luxury I enjoy is that when I am asked to work on a problem (or opportunity) then someone in the company already thinks that it is important enough to invest in fixing - so the "magic" is working with that person to understand exactly *what* problem the business needs fixing and use it as a north star to guide my efforts through the project.
That's why I always start consulting projects with an open discussion with the primary stakeholder about what problem they are really trying to solve, why they believe it is occurring and what the real business impact is that it is creating.
This is an outline of the approach I have evolved over the years to do these initial conversations
Problem Statement Approach
For me, the purpose of these first couple of days of the engagement is to listen and understand the business problem and underlying assumptions and then play it back to the business to make sure I have a solid foundation for my actions and recommendations.
Normally during this period I am working closely with two separate people to understand the problem and plan how to address it:
Primary Stakeholder - senior leader who is sponsoring the request, and has a clear big picture vision on what the business problem is that the company is willing to invest my time to get fixed
Subject Expert - hands on business expert who is either part of the team doing the work or directly managing them. This person needs to have both knowledge and time to start getting into the weeds with me on thinking through the issue to be fixed
While the Primary Stakeholder and Subject Expert will agree on most aspects of the problem their perspectives on it are usually somewhat different - the gaps are great pointers to areas where things are not quite as clear or obvious as they might seem at first glace.
1) Initial Conversation to understand problem and possible causes
The first meeting is a "listen and learn" session to gather the context for the issue and its impact. The main questions I am asking at this stage are:
What is the business problem we are trying to solve?
What would you like to be happening? What does "success" look like?
Why do you think this is happening, and in particular, why "now" if it has recently started or got worse?
What happens if we don't fix this?
Most important is to keep this first meeting focused on the problem itself and its causes, rather than jumping straight to solution mode. Their is no particular technique or approach which will solve every problem. Instead the "magic" is understanding each challenge in its context to work out which ones are going to quickly deliver value in this specific situation.
2) First draft of problems statement, mission criteria and root cause hypotheses
Based on this first discussion I then write up my initial understanding of the situation focusing on the following elements:
Problem Statement - Clear description of issue which is to be addressed
Root Cause Hypotheses - Initial hypotheses from Primary Stakeholder and Subject Expert about why the issue is occurring
Mission Criteria - Success metrics, external dependencies and other assumptions which will guide our approach
Coming in from the outside my understanding certainly won't be perfect, but fortunately it doesn't have to be - the purpose is to show what I *think* was described so that the Subject Expert can confirm and/or correct these assumptions
3) Review problem statement with Subject Expert and discuss potential quick wins and related analysis plan
Once I have a working first draft of the problem statement and supporting deliverables then my focus starts to switch from "listen and learn" to working with the Subject Expert to "understand and recommend" how to move forwards.
This usually takes two or three working sessions with the Subject Expert in order to do the following:
Review and update problem statement, mission criteria and root cause hypotheses to make sure I've correctly captured the feedback from the initial conversation.
Additional discussion of root cause hypotheses to get more background on why they might be occurring, as well as Subject Expert's thoughts on relative likelihood and importance.
Propose quick win ideas as potential follow-on activities to improve business if root cause hypotheses are valid. The key is to only consider quick win ideas which are directly relevant to one or more of the potential root causes - having a superb hammer doesn't make every obstacle a nail.
Map quick wins to root cause hypotheses to determine which actions would be recommended depending on which of the supporting assumptions prove to be valid
Develop analysis plan to provide immediate steps to validate root cause hypotheses supporting quick win ideas
Identifying client led items in both quick wins and analysis plan which can be completed without additional support from an external consultant
Based on these working sessions we'll then prepare the final proposals for both potential quick wins and supporting analysis plan for review with the Primary Stakeholder.
Finally, it's absolutely critical that the Subject Expert is fully onboard with the final proposal so I like to do a final run through to make sure that they
Understand what is proposed for each quick win and analysis plan item
Agree that the quick win items would help the situation if the related root cause hypotheses are supported
Agree that the analysis plan items will be enough to determine whether the root cause hypotheses are valid or not
If there's anything in the proposal that the Subject Expert isn't fully onboard with its best to simply leave it out.
4) Make action plan with Primary Stakeholder / Subject Expert
The final step is to take the proposal back to the Primary Stakeholder and recap the discussion with the Subject Expert
Discuss quick wins and agree which are most likely to improve situation - if root cause hypotheses are valid
Prioritize analysis plan items to test hypotheses which drive the highest value quick win actions
Confirm internal resources are available to support activities identified by Subject Expert
If the review with the Subject Expert went well then this should be a simple and effective process since they will help to back up the proposal and translate it into the local context, but there are still likely to be a few updates to incorporate the primary stakeholder's feedback.
Once the quick wins and analysis plan are confirmed the last steps are:
Estimate timing for prioritized analysis plan items for both client led and externally supported items
Schedule health checks to track progress on planned actions. It's important to keep these fairly frequent during the analysis phase so I tend to start with meeting every 1 or 2 weeks and then reduce to every 2 to 4 weeks as the project gets underway.
By first validating the root cause hypotheses this approach works even if it turns out some of them are not to be supported by the data. It also provides a structure to incorporate any new root cause hypotheses identified during the analysis phase or raised by wider stakeholders.
Thank you for your interest to read this far - this is a process I've come up with on my own over the years and I'm always looking for opportunities to improve so I'd love to hear feedback and alternative approaches.
