IT Project Mechanic

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 guess 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.

Today begins the first in a series of entries about focusing on the basics of Project Management. With all of the “flavors” of Project Management these days (Scrum, Agile, traditional, waterfall, RUP, CMMI, etc) the basic tenets of any PM methodology are the same – help remove risk, ensure optimal performance and deliver the project you’re chartered with managing.

I want to start with Scope Management, the practice of defining what the project is supposed to deliver and what areas the project will not attempt to address. This is the fundamental component that separates projects from operational work. The reason that projects can fall behind schedule or miss the expectations of their customers primarily lies with inaccurate scope development or management. This uncertainty doesn’t just lead to project impacts with schedule, budget or team – if left unchecked this uncertainty can impact the client’s confidence in the team, or impact the team’s morale. (more…)

Well, if you have tried to visit us in the past 24 hours you may have experienced some funky behavior or maybe been unable to get to the site.  We saw the need to change hosting services and this has caused a few glitches that hopefully are finished.

Please, stick around  – this should be the last momentus change we make for a while (I hope!)

WBS – wasn’t that some quaint little idea that you had to memorize for the PMP certification and then promptly packed away for “future” use? Maybe you’re one of the many guilty practicing PMs who don’t use a work breakdown structure as a cornerstone of your planning activities. Maybe you don’t need a WBS – or perhaps that’s the thought you repeat as you start another project without this tool.

I’m guilty too – but I’m a reformer. I learned my lesson the hard way – (more…)

Technorati Profile
We’re proud to announce the registration of our Technorati profile to the list of connections IT Project Mechanic is associated with.