I have always believed that a good business analyst will be able to work on any project because he or she will ask good questions. At the same time though I have always believed that different projects need different approaches and therefore potentially different skills.
Which begs the question – should our approach to starting a project be based on the type of project or on a generic set of questions aimed at understanding the problem to be solved (or the opportunity to be seized)?
I usually start my projects by trying to work out what is going on. So the first question I ask is “what is going on”?”. But if I use those exact words I normally get a blank stare. So I usually ask what problem is being addressed or what opportunity is being explored to get a starting point.
Then I use my question compass to work out what is really going on. My question compass is a standard-ish set of questions I like to ask when first engaged on a new project. Many business analysts have a similar set that work just as well (in other words they have their own compass, I guess).
The theory behind this is that people are often wrestling with the symptoms they are experiencing rather than the root cause of the problem. So the first benefit a consultant can offer is to help the client clarify their own thinking.
(editors warning – this is a long article for a blog so grab a tea and come back, skip this long winded commentary or shift your brain into skimming mode before you continue)
My question compass
I have written about my question compass several times in different contexts but I recently got asked how I use it at the start of a project. So here is how it goes:
I say hello and ask what the problem is. Then the client tells me what they think is going on. They say something and then I launch into my question compass, starting with “what do you mean” and then moving through the compass points until I know enough to be either scared or curious.
What do you mean?
The first question is “What do you mean by …”. But here I use a not-very-sophisticated technique called “nouns and verbs”. Rather than just saying what do you mean, I pick specific nouns and verbs and ask specifically what the client means by that particular word:
- What do you mean by (insert noun: for example “customer” or “poor service”);
- How do people currently (insert verb: for example “make requests” or “run reports”);
- I go through enough nouns and verbs to annoy people a reasonable amount and then I pause to look serious for a moment to finish this part of the compass with the question “Hmm … I see … so how will things be different if we “what we are doing”?
Oddly enough, the more indirect my questioning (asking about any old noun or verb rather than really trying to burrow into the problem) the more my client seems to ponder the problem and suddenly realise they were solving the wrong problem. So I often know when to ask “How will things be different” because my client says “ah ha – I think the real issue is blah”.
Why? Why else?
Having annoyed my client a little by asking about a lot of nouns or verbs, you might hope that I would be able to jump to solution mode. But usually I start the grilling session again with “so why do you think people are having that issue?” or “why is doing that a good idea?”.
When I get a response I then ask “why else?”. That may seem an odd question but I have found that, as the old saying goes, we often do things for two reasons – the right reason and the real reason. So I like to get find out if there is a second reason like “our competitor is doing it”, “my boss wants it”, “that’s how we did it in my old job”. These can all be valid reasons to consider something but are not always things that people feel like they can own up to.
At Toyota, apparently, they use the 5-why’s to get to the root cause of problems. So rather than ask why once they ask why a lot. I find this can also be useful, but people lose patience with me in an initial interview so I often only get two or three why’s in before I disguise them with another “what do you mean” or “how do you see that working”. But I do concentrate on hammering away at the why.
Is that true (or are you lying to me)?
Once I have run out of energy with the why’s then I ask my client if they are lying to me. But people seem to react badly to that question so I have started to disguise it with more friendly versions:
- How do we know that is true? What else could cause the same thing?
- What would the team say if I presented that to them?
- Is that also how the customer would see it?
- Who else might have a different view?
- How often does that happen – all the time; most of the time; or some of the time?
- Does everyone do it that way?
- Is that always the case? What exceptions are their?
- So let’s just walk through how it will work. A client comes in with a requestion for a new invergolation routine (invergolation is a made up word, not a real term). What is the first thing that happens, then what?
- If you couldn’t implement a system solution what would you have to do instead?
- If that is what we are doing, what will people do before we implement it? Once they do that, will they still want the same solution?
- That’s one solution. Lets just run through 7 or 8 more (hmm – am I lying to you with that one? In some cases it really is worth running through a bunch of alternative solutions even when you think it will work).
- If we could only implement part of the solution, which part would make the most difference? What if we only did that, then came back to think about doing more later?
So you can see that I am not really seeing if the client is being dodgy. Instead I am testing the boundary of the solution or problem.
“Yeah … so what?”
Possibly not as bad as “are you lying to me” but not likely to win me many friends.
So again I have to disguise my question to make it sound nice. But if you ever call a good help desk then “so what” is about their third question. They ask who you are, then what the problem seems to be … then they usually ask “how many people are impacted” in a corporate environment, or “what is it stopping you doing” in a customer one – and both these questions are really variants of “so what”.
The typical so what questions I ask are these:
- What will happen if we do that? What else might happen?
- What do we know we should do, but probably won’t do? For example, will we defer something to “release 2” then “release 2.1” then release “now+1”?. What impact will deferring that have?
- Who’s support do we need? Who else might be interested if we can deliver this?
- Who is likely to get in our way? (in evil projects – how can we eliminate them as a threat? In projects working for the forces of light and goodness – How can we gain their support or address their concerns?”
- Who else needs to be involved?
- What is likely to happen in the longer term if we do this? Will there be ongoing support? Will this really be a stop gap, or is this the long term fix?
- If this takes time to implement, what should we recommend people do in the short term?
- What would happen in the short term if we didn’t do this?
- What might happen in the long term if we don’t do this? Will it go away? Or will it fester and become a bigger issue over time?
- What else has to happen to make this work? Are there process changes, training needs, political issues?
- What are we hoping will not change if we do this? what if it does?
- What will be the residual issue? in other words, what will this not fix?
- How will we support this? Who will we hand it over to?
- What could go wrong if we do this? What would people be worried about? What should they actually be concerned about?
Once I have finished all of this questioning (it can be done in anything from 15 minutes to 1 hour) then I think I have a pretty good grasp of what we need to do.
Then I can move to logistics, planning and getting others in for more investigation.
But on the other hand, other BAs and consultants have their own question compasses, so is mine the best or should you try theirs?
And on the other hand again, are these questions the right ones for all projects, or should we use different ones based on such things as whether the project is about, for example, consolidating and improving our processes, or launching an innovative new product?
I guess those are things worth more discussion, but I suspect you need a coffee break if you are still reading through my long-winded explanations. So I will leave those questions for next time.