Defining the Problem

More than six months into a project our project team found itself wondering whether we were really headed in the right direction. We thought we were doing well enough until a month ago when we compared notes with another team that was doing a similar project in another Province. We thought they were doing cool things like tackling the challenge (coordinating road investments) at the Provincial level – while we were doing the same thing at the Municipal level. And they were spending a lot of effort crafting a criteria for road investment prioritization while we accepted our Municipality’s road priorities (which we believed to be aligned with their respective strategic directions).  These differences led us to thinking about whether the other team’s initiatives were applicable to us. Moreover we asked ourselves, “why didn’t we think of these things at all?”

So we agreed to hunker down and sort these questions out. Nobody was quite sure where to begin, though.  When my boss asked me to facilitate the discussion, I found myself going back to the things I’ve been used to – since High School. I remember our Science teacher told me each experiment begins with the statement of a problem. A clear problem statement establishes what we’re concerned about – and what we are not concerned about. It also sets the basis for our hypothesis, which we will then test through an experiment.

So I asked our group, “what is the problem that our project intends to address?”  That sparked quite a few ideas, like “the percentage of roads in good condition is low”, and “the amount appropriated for road projects is low”. When I challenged the group to back up these problem statements with data, they went back to facts and figures they had gathered the last few months.  They presented the relevant data and we talked about whether the facts support our problem statements. In the course of the discussion the group came to the consensus that the problem is not really low funding, or the percentage of roads in good condition – the problem is that people can’t go from production areas to markets or transhipment areas, and can’t access basic services, because the road segments that connect these areas are not all in good shape.  This is because these segments are under the jurisdiction of different forms and agencies of government, and nobody is making sure these agencies are coming together to fund those stretches that make up a significant road link. Note that those two last phrases are problem statements by themselves.

From these problem statements the group proceeded to post theories about how these conditions could be reversed. There was still a lot of debate and discussion, but everybody could refer to the problem statement to see if the ideas presented were relevant to the problem.  We even saw that much of what we had been doing in the last few months are actually related to the problems and are part of the solution.

Lesson learned – it pays to have a clear idea of the problem that we are trying to address.  Once the problem is clearly stated you have a reference that will help you filter ideas – are they relevant to the problem?

One more note – somebody once told me a problem is not a problem if it is nobody’s problem. A condition becomes a problem because somebody suffers because of that condition. So when you define a problem, be sure to identify the people who are affected by it.

Do you have a clear understanding of the problems that your projects are intended to address?