When most projects start out they have an identified problem that is driving the effort. Every project I’ve been a part of, or can think of for that matter, has at it’s core a problem, perceived problem or need that is moving people to action. I believe that a large number of these projects are scoped to “fix” the wrong problem.
The costs (and the subsequent wasted funds) of missing the problem aren’t trivial – but many refuse to look at alternate ways of defining their organization’s problem discovery process. This isn’t a formal process in most places – it’s a gut reaction from leaders who see symptoms from a problem and act decisively to resolve it. Unfortunately, the ROI payoff on this method of problem discovery isn’t all that good.
I’d like to describe two methods of defining project problem statements and let you make up your mind as to whether your methods of defining and developing project problem statements could use an upgrade. Understanding this “black art” isn’t difficult; applying these methods however touches other culture hot-buttons that make using them more interesting.
The first is the 5-whys technique. This requires the leader to ask probative questions though 5 rounds of asking “why”. Through each successive round of questions, further details are revealed about the problem and it’s nature. A classic example is:
Q: Why were you late for work?
A: Because my car wouldn’t start. Q: Why (1)
A: Well, I was out of gas. Q: Why? (2)
A: I spent too much at the sports bar and didn’t have enough money to buy gas.
You get the idea. This process doesn’t require the user to ask a precise number of “why” questions – the goal is to find out the cause of the problem – in this case a lack of funds. Sending a tow-truck out for the person’s car wouldn’t help the matter – but many organizations choose to take the first symptom they see and craft a project around it.
The second method is similar, but achieves the goal differently. Describing the problem in a statement is the first of three steps. This statement can’t propose a solution; it must be a strict statement of what the problem is. This is difficult for many who’ve been trained (i.e.: conditioned) to never discuss a problem without a solution. Once the problem statement is completed, the next step is to look at the current process (or how you interact with/around the problem activity).
This could be a flowchart of the process used to describe the steps before, during and after the problem activity. It can also be a
meeting with sticky notes to define the steps, the circumstances around the problem, etc. The crux of the activity of describing the process is capturing the context of the problem – when does it happen, how does it occur, etc. Knowing what actions are happening around the bit that’s not performing to expectations (the problem) can be invaluable to the final step – identifying the core/root cause of the problem.
IT Operations Managers have been defining root causes to problems for years – the pain of revisiting technical failure many times before the real issue is resolved cost the organization too much in goodwill and financial losses and good RCA (root cause analysis) practices came into existence. The same activity needs to occur for functional/technical problems that kick off projects – in many cases the initial symptom has little to do with the root problem, and likely disappears when the root problem is rectified.
My belief on why this process isn’t leveraged as often as it should be is relatively simple – many organizations are “jacked up” or dysfunctional beyond what their public images display. Digging into the core problems of an organization isn’t popular or good for your career, in general. If the leaders of the corporate culture define a move toward honesty around the state of internal process and develop ways to capture and prioritize the items that are discovered, this can allow process root cause development to flourish and make the project results more valuable, immediate and tangible.