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.

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!

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

Six Sigma isn’t necessarily built for manufacturing environments. That was the original intended purpose, to be sure. The methodology, however, can accommodate all systems based improvement efforts that may be pursued. The other facet of the question, “How can Six Sigma work for IT projects?” rests on whether the technology based processes are known systems.

This question has a very simple answer – IT projects and processes are systems. They do not take on the physical shape of systems as manufacturing facilities might, but the repeatable series of steps and the defined methods used to execute an IT Project are very similar to all systems.
(more…)

It isn’t enough to be right, or to have an idea that will make the problem go away if you are presenting something “new”. In a majority of cases, others (that you work with) are reluctant to believe an idea or position that they aren’t familiar with. It’s not a trust issue, per se, in many cases – it’s easier to say no than to think about the idea presented and formulate a response. No is easier than accepting that a good idea is out there they didn’t think about. It isn’t a universal truth – but this happens more often than not.
(more…)

In nearly every case, I witness and experience the act of selling as a Project Manager. On a daily basis, I provide to my clients the same exact steps as a consultative sales professional does. There are two distinct differences between the sales professional and the Project Manager:

1. The Project Manager doesn’t “sell” as a full time job – it is a skill that is needed for parts of the project management method.
2. The Project Manager rarely “prospects”.

The first difference should not come as a shock – the fact is that PMs have lots of skills that we use to great affect that don’t consume a huge amount of bandwidth. The second difference may not make any sense if you have never had the fortune of selling or have been exposed to the selling process.
(more…)

Most Project Managers think selling as a PM’s skill is some sort of an oxymoron – being a PM is the opposite of selling. You manage and report the facts, deal with estimates and manage a group of people. The sheer fact of the job limits the ability for a PM to sell, right?

I couldn’t disagree more – PMs must sell, and we sell every day. Some call it negotiation, some call it “positional” authority, but break it all down and we’re selling our hearts out to get the project out the door. We sell to and with our team, to our stakeholders and definitely selling is an integral part of the client relationship. Don’t worry; I’m going to explain my assertion.

(more…)