IT Project Mechanic Blog
  • Search

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.

Comments No Comments »

I’ve been a proponent (much to the chagrin of some of my team mates) of the idea that organizations don’t understand the problems they’re trying to solve for quite some time. This sounds absurd on the face of things – why would an organization sink time, money and resources into a solution for a problem they don’t understand?

Fact is, most folks participate in “blind solutioning” (fixing a problem where only the symptoms are well known) and aren’t aware of the damage they cause – I’ve been met with anger, disbelief and denial whenever I try to gently bring this to the surface. Like it or not, so many projects start out with an assumption that a product is the answer before any time is spent determining what needs to be rectified in the first place.

There is a great interview of two chaps that illustrates this well – http://innovations.ziffdavisenterprise.com/2008/04/stop_thinking_solutions_start.html

I plan on digging into this more in the coming weeks – stay tuned!

Comments No Comments »

Well, there is one constant for our technology ladened world – things change and innovate fast. There is a new website with a killer mission – to give all that what it the opportunity to create their own comic strips. Pardon my inner-kid, but that is soooo kewl!

So from time to time I’ll be crafting and publishing some humor and informative strips for your viewing pleasure – here’s my first about the infamous 3 month rule (that is, when you’re saddled with a project that someone else started, like a contract PM who is no longer there, that you have a get out of jail free card for a 3 month extension). I’d like to note that I don’t like/approve/exercise the 3 month rule – but it’s out there and a little satire now and again is good for the soul.

Comments No Comments »

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. Read the rest of this entry »

Comments No Comments »

For many, the task of filling out the PMP certification application can be more daunting than the exam. Fear not, however, for there is an easier way.

The most laborious task is Section III, the Experience Verification form. Now, while this form is straightforward, it should help you save time and anixety when you are filling out the application for the exam online or offline. Just remember, PMI isn’t judging the ‘quality’ of your Project Management as a part of the application process; they are judging whether you have the required experience to sit for the exam. Similar to your resume/CV (but much more detailed) break down your project portfolio you plan to use and decompile your projects one at a time. It’s tedious, but for a PM ready to sit the exam, it should be old hat.

Here’s that form – I ask that if you choose to pass this on to keep the identification information in tact as a courtesy.

Experience Verification support form for the PMP Application

Comments No Comments »

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

Read the rest of this entry »

Comments No Comments »

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. Read the rest of this entry »

Comments No Comments »

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

Comments No Comments »

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.

Read the rest of this entry »

Comments No Comments »

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


Comments No Comments »

  • Copyright 2008 by RPMC, LLC - All Rights Reserved Please enjoy and use our ideas and information - stealing/plagiarizing however is unethical and won't be tolerated