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.

I’m blogging at www.ittoolbox.com/pm/itprojectmechanic and thought you might want to review the article that I posted there called “Why am I doing this?”

You can visit the blog here: http://blogs.ittoolbox.com/pm/itprojectmechanic/archives/why-am-i-doing-this-23212

(more…)

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

If you have spent time in a few different IT shops, especially project shops, you probably have noticed something about processes. This is something that drives me bonkers about how people implement process. While this is designed to be somewhat humorous, this is potentially hazardous stuff and should be taken seriously…

Some places almost outlaw process – “we don’t need it” is the assertion.
Some places embrace process toward religious extremes – “too much process isn’t possible” is the claim.
Some places take what’s just right – and only what proves to be worthwhile pursuing.  (more…)

Do you know how your project’s performing? Are you sure???

Measuring project results occurs in every project – task completion, performance to schedule, etc. Many PMs, managers and leaders believe that the efforts they are making toward measuring project results are “good enough”. There are, however, potentially fatal mistakes (figuratively) that can be made in managing the data collection and analysis of project measurement results. You can’t manage what you can’t measure is almost a cliché – but this saying has never been more appropriate.

So how do you avoid the 7 deadly sins of measuring project results? Knowing what to avoid or stop doing is half the battle. If any of these sound familiar – stop it! Set out at the beginning of your projects to define a data collection & measurement plan and strategically develop your method to measure your project’s success.

Here they are: (more…)

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…)

The single most important component of project management is communication. Communication is also the one area discussed by PMI and the PMBOK the least and largely left to the imagination of Project Managers. The Standish Group produces a report titled “The Chaos Report” in which they review IT Projects and various aspects of managing projects in IT. For years, the ratio of successful projects against the whole has been at or below 1:3 – that is only one out of three projects are successful. Up to 81% (in one survey) of IT Projects are unsuccessful for one reason or another.

In the forums presented by the Project Management Institute, and featured in PM Network magazine, there are surveys that cover a wide range of topics. One of these was “Why Projects Fail”. Out of 193 respondents, 167 of these said that communication related issues were the primary cause of failure in their projects.

So, not to understate the point – this is a giant, vital and clear project success factor you have to become an expert in if you hope to deliver projects.

There are a few truths about project communication that go without saying:
(more…)