Problem Solving Step 1/7: Defining the Problem
Defining the problem AND getting on the same page from the get-go!
What are we trying to solve, exactly?
The first step in the process is to spend some time exploring what it is, exactly, that we are trying to solve. We have all had experiences where teams waste time because “we weren’t all on the same page”. The first step in the process is to, literally, get everyone on the same page by writing down what the problem is and the various facets surrounding the problem.
The McKinsey 7 steps are:
Image taken from freely available http://docslide.us/business/mckinsey-staff-paper-66-mckinsey-approach-to-problem-solving.html
We start with defining The Basic Question to be Resolved. This is our overarching guiding light. In doing so, there are a number of other elements that should be considered to give this Problem Statement helpful richness. The elements include, but are not limited to: Context and perspectives, Criteria for Success, Stakeholders, Scope considerations, Barriers to Implementation and Key Sources of Insight.
Although I have written my thoughts and tips and tricks on how to get good outputs out of the process – do not get caught in a judgemental trap of fixating on the perfect SMART Problem Statement. The critical value in this step of the process is the discussion, the debate and the alignment of the working team and steering committee. Talk, talk, talk. Collaborate. The only push I would make is to marry the talk with a page that documents the key “so whats” from the discussion. Leaving things in people’s heads is inherently dangerous. Literally, get on the same page. Write things on the whiteboard and challenge and argue and debate until everyone is “okay” with the page you are on. This is the best chance you have of ensuring people are indeed “on the same page”.
Now, let’s have a look at the different elements and how to use them.
The Problem Statement: the basic question to be resolved
This will be the teams guiding beacon out of the gates – making sure we all get off to a good start, running in the same direction towards a common finish line. We can and will revise our direction and destination along the way, but if we all start off running in different, uncoordinated directions from the start, we are bound to waste time.
I would very strongly suggest developing this Problem Statement both top down and bottom up. In preparation for your kick off meeting or Problem Definition Working Session, I generally get each person to take a crack at writing down and bringing their version of the Problem Statement. This ensures that everyone is prepared – but it also allows you to have insight into how different team members are thinking about the problem and their level of (mis)alignment.
You can then put all versions up on the whiteboard and look for common themes and areas of misalignment and discuss these – do not use PowerPoint! This is a working session not a presentation.
Pull together a top down Problem Statement using everyone’s input and debate and write it at the top of the whiteboard to be referred to during the session.
I would then tackle the other elements of the Problem Definition Working Session and keep revisiting the Problem Statement to ask: “how does this perspective or insight change or add to our understanding of the problem?” – i.e. further building on our Problem Statement in a bottom-up fashion.
A philosophy that I have found works time and time again is building a problem statement that is SMART.
- Realistic and Relevant
Some tips on how to make this framework impactful
The basic question to be resolved should be specific enough to be helpful. Broad questions aren’t helpful as they leave the solution space too open. A certain level of specificity is helpful to channel our efforts in a particular direction.
Example of a broad, vague question: “What should I do with my life?” is a silly question no matter how much whisky one has consumed.
Example of more specific, helpful questions:
- “What should my next career move be?”
- “What should I do with my free time?”
- “How can I add more spirituality to my life?”
You can see the difference between a broad existential crisis versus questions that are broad enough not to jump to conclusions but not so broad that they are unhelpful.
Equally important is not being too limiting. Asking: “Should I take up cross-country skiing?” is a little limiting. It may be a hypothesis but at this point in the problem solving process we want to uncover the context and reasons behind what it is we are trying to solve. Cross-country skiing may be one of many options to trade off – this is the start of divergent thinking so a broader question like “What should I do with my free time?” is more appropriate and constructive.
A good Problem Statement gives me direction without giving me a destination.
Especially in business, incorporating measurable elements to our Problem Statement can help make it more specific. What is the key performance index (KPI) or KPIs that we are most interested in and how much do we want to move them?
Poor: How can we improve sales performance?
Good: How can we improve top line sales performance by 20% to hit $200m revenue in Q3?
The measurable gives us a quantum indication. It gives us focus. And it also defines the key Criteria for Success (which we will talk about shortly).
Going back to my existential crisis: “What should I do with my life?”
What about: “What should I do with my 8 hours of free time on Saturdays?”
Or: “What should I do with my 4 hours of free time after work on Monday evenings?”
Or maybe: “What can I do with my free time from 6 – 7am each weekday to lose the 20 pounds I gained on vacation…?”
Can you see how the measurable adds a vital perspective to the problem…
Action orientation ensures that we focus on impact. What are we going to change? What are we going to do?
Organisations that are very Thinking oriented run the risk of researching and understanding without closing the loop on “So what do we do?” and execution urgency. Making sure we stay action-oriented adds a vital element to the approach. Allow me to demonstrate:
Poor: “How can we understand ways to improve sales performance?”
Better: “How can we improve sales performance by Q3?”
Subtle, but an important nuance in terms of execution expectation and urgency.
“What cultural transformation initiative can we launch in Q2 to improve top line sales performance in Q3by 20% and hit our $200m revenue target?”
“What morning exercise programme can I implement from 6 – 7am each weekday to lose the 20 pounds I gained on vacation…?”
Can you see how each element helps support and reinforce the others to add richness?
We haven’t jumped to a closed question like:
“Should I do crossfit from 6 – 7 …”
or “Should I go for a jog around the park from 6 – 7 …”
We are adding more and more richness to our problem statement so that we have a good direction but don’t have the destination.
Realistic and Relevant
Don’t set yourself up for failure by either setting your sights too high or by solving an issue that doesn’t directly solve the problem.
Examples: If the best quantums of improvement in your organisation have been in the regions of 10 – 20%; setting your sights on a 200% increase in productivity is probably a little aggressive.
That’s not to say that you should set aspirational targets. Debate it. Unpack it. Triangulate it. Test to see if it is too unrealistic.
If NASA had set out for Jupiter without first reaching the Earth’s moon, you would have thought them to be a little silly...
Similarly, if I really want to explore what to do with my mornings to lose 20 pounds, it doesn’t make sense to make my problem statement “How can I be more disciplined in life?”. Although that may be a worthwhile problem to solve, it wont directly help you answer the real question. Be careful of going off on tangential, broad issues that may put you in danger of not solving the real, clear problem.
Test for relevance.
This is a vital element of the Problem Statement. I love this demonstration:
How would your answer to addressing world hunger differ if I gave you 6 months to implement an initiative versus 10 years?
Time can be constrained in a number of ways:
- Time to impact; time to when we need to see results
- The amount of time we have to find a solution (linked to the above). I.e. we need to implement something by x date (could be execution opportunities, etc)
- The size of the team / resources at hand – a team of 2 can do so much in 2 months versus a team of 10. This is often a trade off
(“If you give us x then we will have this kind of solution in 2 months but if you only give us y, you can either have a crap solution in 2 months or you should give us 4 months to work on it…”)
Alternatively, the team may have more time than usual. E.g., we have a development window that is opening up in 6 months time for 3 months. We need to design and spec the solution in the next 6 months
As you saw earlier, it is very difficult to put a measurable and an action into your Problem Statement without considering the time dimension. My push is to remember that time is a key input into the process and if this is constrained, it is important to unpack and understand the trade off that result on both the process rigour, level of solution and timing of impact – these are trade offs.
The Supporting Elements of the Problem Statement
Context and Perspectives
Very simply, “Why are we here and why are we trying to solve this problem?”
Different key stakeholders may have different views on this: Finance needs to achieve x performance while operations needs x performance to pay y commission and retain sales reps…
It is invaluable for the current working team to get a group download of:
- the context leading up to the problem
- who is effected by the inefficiency and why
- what has already been tried in terms of addressing the problem
- what do different stakeholder believe potential root causes are
- what hypotheses do different stakeholders have in terms of solutions
Capture key takeaways to refer to later (on the whiteboard, transfer to PowerPoint or Word offline). Circle back to your top down Problem Statement and see if any more insights have emerge in the conversation to better shape the Problem Statement.
Criteria for Success
Although this should include your Measureable in your Problem Statement and you may have had a debate on this already – it is worthwhile exploring criteria for success in richer detail. Some questions to consider:
- What is the teams actual output to enable the change? Is it a new training programme? Is it a recommendation to the executive? Is it a business case for a new opportunity to be signed off by the executive and then left to operations to implement? What exactly is the working team’s output here? We all want impact but we have different roles in making that happen – be specific
- What are the softer elements? “We want to double our sales force but we don’t want to damage employee morale or culture in the process.” Great – write that down as a Criteria for Success!
- Who owns the answer? Is there a level of skills transfer to a line owner? What change management elements do we need to consider? Who needs to be excited about this initiative? Write that down!
I always defer to “Guys, what will the world look like when we open the champagne?”. And then I write that down!
This does not only include people effected by the change. Stakeholders include:
- Who is on the working committee?
- Who should be on the working committee?
- Who is sponsoring the project?
- Who is owning the project and responsible for the deliverables?
- Who are the key stakeholders for implementation and execution?
- Who are other key stakeholders in the process (software development division?)
- Who is going to be impacted by the outcome and how are they going to feel about it?
For critical decision makers and execution owners, I would strongly suggest determining which member(s) of the working team are going to “own” that stakeholder. Keeping them up to speed. Ensuring they are incorporated in the process appropriately. Building the appropriate working relationships with the individuals ahead of time. Write that down! Get on the same page.
Simply, what is in or out of scope.
Are we focusing on a particular part of the problem or organisation only? What solution space can we consider versus not consider?
“You want a 20% improvement in top line revenue – do you want us to only focus on sales improvements or if we see opportunities in your cross-sell income, should we look at those opportunities?”
“Nope, our sales force is below benchmark so we need you to figure out how to up their game by 20%.”
“Do you want 20% across the board, or can we focus on getting the East Coast up by 30% and not work with the West Coast – and still improve overall performance by 20%?”
“Can we fire your bottom 30% of performers and hire better salesmen by paying them more?”
“No, we don’t want to unsettle the corporate culture at this critical time. No firing over and above our existing performance management processes”
“Our problem statement and criteria for success states that you want us to help you develop a training programme to improve sales skills and their performance. However, there may be opportunity in how you allocate / match your salespeople to clients. This could be a highly value adding piece of work but will take significant time and effort – and a mandate from you to change the current process. Do you want us to expand our scope to cover that or just focus on the training programme?”
This is just an initial conversation but it is worthwhile testing to see if there are any glaringly obvious scope considerations that may change the focus of the team. As the project progresses, threats and opportunities will pop up that will make you want to revisit scope.
Barriers to Implementation
Are there any major issues or constraints that the team needs to be aware of in shaping the solution?
“We are a highly regulated industry, if you solution doesn’t talk to the regulations, the regulator will never sign off our implementation plan”
“We have just come out of a major cost cutting exercise so morale is at an all time low. We need to think about how we excite the organisation to put effort behind this or it may fail at implementation stage”
“The business analyst who built our data architecture was eaten by a shark two weeks ago so we are busy unpacking and relearning the core rules and relationships. This will slow down the data integration of the solution considerably”
“The Manager of the New York Office is a real piece of work – highly ambitious, territorial and considered to be quite arrogant. If you don’t make him the champion, it will never fly on the East Coast.”
Consider both all the elements of the process:
- Access to data and insights
- Access to people
- Sign off of solution
- Implementation and execution
- Regulations and risks
Discuss them, understand them, then figure out a way to address them in the process or solution to create a greater chance of success.
Key Sources of Insight
Are there specific people, research reports, data or analyses that will give the team great insights into the problem and potential solutions?
“We have been wanting to internally benchmark our sales force and determine where the high value pockets are, we just haven’t had the time”
“You need to pull Tom into your working sessions – I have no idea what his job description is but he knows that plant backwards”
“Gartner has just published their annual Business Intelligence matrix – this will give you the latest thinking on where our current tools are performing relative to the industry”
“We have worked with the specialist LEAN consultants before and they were really helpful with implementation. Let us know if you want to chat to them and possibly pull them into the implementation stage”
This is one of those, “if you don’t ask, you will never know” situations. I have always found it worthwhile putting this on the agenda. When you get the team problem solving around Key Sources of Insight, it is amazing what pops up.
Again, the real value in this step is not to tick the boxes – it’s to have the robust debates and conversation around Defining the Problem and not solving the problem. This draws a ton of insight into the process from the outset. It gives the team enough direction to be efficient, without giving them a pre-determined destination.
WRITE STUFF DOWN!
Get everyone on the same page. Use a white board. Use two whiteboards. Do not be constrained by PowerPoint templates and font size. Document anything that seems important and insightful. This is the page you are getting everyone on to kick-start your Problem Solving Process.
Make it a big, rich, shared and helpful page!