A clear sign of a poorly identified the problem is irrational disagreement. You’ve been in these meetings: one person brings up a great idea, another shoots it down immediately, and participants voice conflicting opinions about said idea. This conversation quickly degenerates and you know, instinctively, you’re going to leave in 45 minutes without accomplishing anything, except adding yet another gray hair to your head.
These conversations often occur because participants differ in their opinion of what the problem really is. The dialog is laden with solutions and each person internalizes how each solution might solve their particular version of the problem.
What Can You Do?
The step you absolutely must take is simple. Simply say:
“I think I might be missing something here. Can you clarify for me what problem are we trying to solve?”
Let the conversation shift as people state their version of the problem. But you are not done yet. Many might bring up their solutions as problems. And some might have trouble articulating what the problem really is. Reach into your facilitator’s bag-of-tricks for multiple ways to refocus the discussion without sounding irritating and redundant.
- If we did XYZ, what would happen?
- What benefit does XYZ have?
- What would change once XYZ is in place?
- How does XYZ change things?
- Why should I care about XYZ?
- What’s your goal? (or, the goal)
- How would XYZ impact you? (good technique to shift the conversation to a non-participant)
- What else do we need to think about if we do XYZ?
- Let’s talk about what problem we might be trying to solve here. (yea, it’s often necessary to re-iterate, just re-phrase if you can!)
- How would your day-to-day work change if we did this?
I could go on, but then I’d risk sounding redundant. And I know with this list in hand you’ll be able to come up with your own ideas for asking why with finesse. The important thing is that you be persistent in your pursuit of the real problem and don’t stop asking questions until you’ve got agreement from all participants on what the problem really is.
Chris Matts (https://twitter.com/PapaChrisMatts) describes this as “popping the why stack” – you keep asking “why do you want that?” until you get back to something that is recognisablle as business value.
An example from a recent project for me, to put a procurement system (applications and processes) in place:
X: We need to be able to raise purchase orders with 12 line items.
A: Why?
X: Because we have to have one line per month on each purchase order.
A: Why?
X: So that we can receipt services received each month.
A: Why?
X: So we can run a report of anomalies between services receipted this month and the line item.
A: Why?
And so on (of course, not being so rude and blunt as to just ask “why?” each time!) until you get to the real reasons – so that they can make sure they’ve not overlooked any services that were expected to be done this month, so they can check the quality of the forecasting over the year, to act as trigger for redistributing the approved spend of a different timescale, and a few others.
Depending on the project, you might want to pop those a bit further, but for us this project that’s where we were hitting our “value” layer, as those items were part of the business environment into which our project was to fit (not things we had a brief to change.).
Nick
Oh, for that project we found a solution that wasn’t to put 12 line items on the PO, which was going to create a lot of work elsewhere in the organisation – the PO had “true” line items about the expected deliverables, and the procurement system was able to track estimates of accrued work separately, linked in to the service receipting, with no extra (BAU) work for anyone.
Nicely done Nick!
I agree with Jonathan, define problems AND opportunities first, set objectives and scope, then get into requirements. Just jumping into requirements, or worse – solution -. first is disastrous.
Thanks, Gulli. These are some great additional ways to figure out the problem. And you are right, people often assume there is a problem where none exists. Or, more often, I find people assume there is a big problem with a meaty solution where a bit of questioning reveals a much simpler path.
good discussion, some additional questions to ask:
Why is it a problem?
For whom is it a problem?
What are the consequences if it’s not solved?
People seem to take for granted that a problem is a real problem, sometimes it helps to ask why it is a problem.
Good site, Laura, keep up the good work.
Nice post, Laura. And I like the new look for the site, too.
Good to see you draw attention to the importance of identifying business problems. That is such a critical task, and one that probably doesn’t get the attention it deserves.
Products (or projects) start with a problem to be solved. If we don’t get the problem right, it’s hard to imagine us getting the objectives and requirements right. From there, it’s hard to imagine a product coming out of “the factory” that will meet the customer’s needs.