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.

Having implemented a “few” PMOs, I can share a phenomenon that many of you can relate to - the notion that “Portfolio Management” or “the PMO” is going to make an IT department’s situation different because of their existence. I can sadly say that I’ve heard too many seat pocket ideas (like those found holding executive magazines in airplanes) blurted out with conviction, such as, “Well, we have Portfolio Management/a PMO/fancy software - why is this happening?” when problems persist. (more…)

Every PM I have met along my journey has had at least one, if not a few, projects that could be modestly described as troubled. In fact, I think this is a pretty standard occurrence in the Project Manager ranks - there are projects that despite our best efforts, quality training and experience, spend a majority of their time classed as Red or Yellow on a status report. Why is this happening? Is it the PM? Surely there must be one bad apple spoiling the bunch, right? Someone has done something wrong - that’s why we’re in this situation… Right?

Sadly, I’m afraid our friends in the Quality world have it right - it’s not the people, it’s the process that normally causes things to go awry.

(more…)

I was surfing the blogosphere and ran across an article about how Project and Portfolio Management strategy (and software) are musts for CIOs in hard times - I would argue that the belt tightening in lean times and the wild-wild-west rules when times are good is all the more reason to invest in PPM tools for the enterprise.

If you need a tool to tell you what you ought to cut out in one economic climate, it stands to reason that this strategy would work all the time.

I’ve never heard someone say, “Wow, I’m glad we wasted all that money while the stock price was good”… - have you?

PPM strategy a CIO’s must-have in hard times

In the early phases of a project, the team members, stakeholders and sponsors are all focused on the work ahead - they are gathering requirements, setting up a business case or getting familiar with the product that will be central to the project. One of the items that doesn’t get much attention during this initiation phase is project success criteria, or said differently, what dictates project success.

This is an innocent omission by most accounts - there should be plenty of time to capture success criteria. However, more often than not, project teams and project managers alike forget to factor capturing and verifying success criteria back into the mix. (more…)

Project managers are all too familiar with how to manage their team’s performance and their projects -this is a core skill you quickly learn and enhance or you die as a PM.

Project managers, in large numbers, are either freaked out by or don’t know how to manage their leadership, managers and bosses to get the job done. This skill is just as important as the ability to estimate and manage tasks, but is slippery in its approach. Hopefully these sugesestions will help wipe some of the goop off the subject and help you manage your leadership better.

First and foremost - managing up is all about time and place. (more…)

Welcome to the IT Project Mechanic blog - a place where far ranging topics are discussed, analyzed and introduced that related to IT Project Management and the business of managing projects. The first question I can imagine your asking (and it’s one that I have asked myself) is “Why another IT Project Management source of information?”. I have strongly felt for quite some time that the honesty and brutal truth of the PMs operating model is under fire by academics and “clean room” practitioners - that the reality of a Project Manager’s work and driving pursuits is far different from the manuals, books and methodologies that are currently available.
(more…)