Focusing questions and project charters are great, but where do you start?

I am starting a bunch of small projects at the moment and people are rushing to help define the solutions.  That is great but I am (as always) nervous that we are providing solutions before we really understand what we want to solve.

I like to define the problem (or vision) and then a rough plan to get there and with this in mind I have already published an article suggesting teams use a project charter and possibly a product statement, but where do these come from? 

I usually start right at the beginning, by asking people what they want and then asking what they mean by that – I call that approach a “question compass” because it is useful for finding your direction right at the start of things.

But even with all those links, how do you go from “hi, there my name is James – what would you like today?” through to “Cool, here is an initial project charter – it will allow us to address the enclosed focusing question … that will be $3.2M if you choose to continue, have a nice day”.

When I am talking about my world famous question compass the best place to start is with what people want (I told a friend about it and they moved overseas, so it is known around the world).  So I always start with “what do you want?”.  

That may seem obvious, but is it really?

Most business analysts (also known as BAs – experts in questioning stakeholders)  know that people don’t really know what they want, so they generally try to get past what people think they want to get rapidly to the point of understanding what is really needed, rather than what people initially think they want. This is the basis of the “5-whys” technique, the “MOSCOW” technique  and a lot of the “interrogation” techniques that project managers and BA’s learn early on.

But my parents went through a hippy phase and it scarred me early on. I learned that reality is a difficult thing to understand that that people’s perceptions are often more useful.  This might sound scary (or stupid) to most logical BA’s but stick with me – you may find this useful.

Why?

(skip to what if you want to believe in a logical and well ordered world where projects are delivered according to business value and the wise use of available resources)

Most BA “interrogation” techniques are designed to get past initial bias and vague thinking to get to the underlying reality of what is needed. Then they are designed to shave away anything not needed to solve the real problem so that we can solve the real problem and nothing but the real problem. And yet just after we start our well reasoned and clearly defined project, surprising and really sucky (ie terrible) new features appear in the scope. Sometimes these new features appear early but they often crop up right when we are about to go live, or they continually come up in different forms even as the project  manager kills them off.

According to my hippy upbringing, this is because people act on their perceptsions and unfulfilled needs and desires even after they claim to understand reality (people being you an me). This is an inconvenient finding but I often find that even after hours of interrogation, most stakholders use powerful rationalisation techniques to keep coming back to their (often unstated) perceived wants and needs. This is scary news for logic minded BAs – and what is scarier is that it happens to you and me, not just to “them -our stakeholders”. 

Here is how it works.  “Good” BA questioning is designed to cause something called “cognitive disonance”.  This means that we upset people’s current understanding of reality (or their “cognitive resonance”).  Look them up in Wikipedia for a longer explanation … but cognitive disonance is where you believe two things that contradict, which causes discomfort or disonance.

In creating this discomfort, the BA then hopes to reach a “moment of clarity” or an “aha moment”. This is where the stakeholder and the BA both realise that both the initial assumptions about reality are flawed and the real truth is “aha”. Once we reach a moment of clarity then we understand the real issue, problem or opportunity. This often means we don’t need the solution we thought we needed.

Then we can create a problem statement of “focusing question” to keep the team focused on the right problem.  The focusing question would be of the form “how can (we) solve (what) for (who) so they can (achieve some benefit or complete some task).

A simple example would be:

• Stakeholder: I want a new database
• BA: Why?
• Stakeholder: To keep track of customers?
• BA: Why?
• Stakeholder: So I know why they keep leaving, oh – I just want to know why they are leaving. Let’s just run a survey
• Normal BA – good – then our focusing question can be “how can the project team collate a survey of leaving customers to help Stakeholder understand their reason for leaving …
  • better BA: Why?

But in reality (my perception of reality) what happens is that the BA wins the argument and the stakeholder still has a feeling of wanting something else. So they agree to the intial scope and then they still add things.

But why do they add things? Because you moved from their perception to reality (ah – but your understanding of the reality they should deal with). So you are now talking about a solution and yet their initial perceptions, concerns, values, biases and even insghts remain, or come back again with the slightest of evidence (google “confirmation bias”). 

So rather than trying to understand reality (which is hard – just google De Carte or “Sartori and the purpose of Koans”) I start by understanding perceptions. Once you know people’s perceptions then you can talk to them about the problem they really think they are solving and thus you can talk reality and solutions. 

What to do – where do I start?

“Good grief, what a lot of waffle.  I just want to interrogate them to find out what is really needed” the experienced BA exclaims.

OK – so I start with “what do you want?” or in business terms:

• What problem do you want to solve; or
• What is the opportunity you want to sieze.

Then I ask them what they mean by what they said.

Now, after a short or long chat, I move onto Why? Some possible questions are (favourite in bold)

• What will it enable you to do?
• Why is that a problem?
• Why is that needed? Why now?
• How will that be better than the current situation?

Now I can provide a simple product summary along the lines of:

The solution provides [something] to [someone] so that they can [do something better]. Without it [someone] would have to [fall back]

They will often say no -actually, it should blah.  In my question compass I flippantly call this “are you lying to me” because I am saying what (I perceive) they said and yet they are correcting me.

So now I have a simple idea of what they think they will get. Next for the interrogation of what that means (or so what”).

• When and where will that be useful?
• When would it not  be useful? What problem will it not solve?

And then I can help them imagine success:

• What will success look like?
• What evidence will you accept to confirm the solution is working?

And, sadly, I can help them think about failure:

• Will it really happen? If the solution fails, what will have led to that failure?

And a bit more negativity to kick them while they are down:

• What are you giving up? What might you lose when this solution is implemented?

Now, finally I can move onto the focusing question – how can we make that happen:

• What needs to happen to deliver this solution?
• What resources are needed – where do we get them and when would they become available?

Things are looking up as we present our new focusing question

How can two developers and a product owner create an ongoing report that provides our account managers with an understanding of likely reasons for people to leave, so our account managers can address potential issues before they lead to customers contemplating leaving?

Cool, finally we are nearly there.

“Nearly”, exclaims the impatient BA.

I usually stop there and then have a second session to run through alternatives.  This is sometimes done as part of my project charter and sometimes as one more workshop before we start.  The reason is that, even when we share our understanding of our mission, we all generally leap into single-solution mode and work out how to deliver “the one best solution” but that does not exist.

If you have the energy – here is one final link explaining what I mean – the marshmallow challenge.

But now you have started the rest is easier – either brainstorm more than 7 options (for magical reasons I will not explain here) or dive into the project charter.  If you all have the same understanding of the problem and solution, your project will generally succeed.  If not you will work hard and deliver a really good solution … to something.