I recently read an article appearing in CIO Magazine titled “Common Project Management Metrics Doom IT Departments to Failure” where the subtitled mentioned a report by Forrester Research stated the metrics used to measure IT project success influences the perceptions of failure. It goes on to say that we need to change to increase the perception of success instead.
We’ve all heard the adage “perception is fact” implying perception is not fact, it only has the allusion to be factual. I don’t know if it is my sense of humor, but the statement of “increase the perception of success” was strangely funny. Did it mean the project was actually a failure but we make it appear successful? Does it harken to another well-tread cliché, “In project management, we simply redefine the parameters and declare victory. That’s how we have successful projects!”
The article further details four things the PMO can do to help increase the perception of success. While I agree with them:
- keep project steering committee on task,
- improve communication with project sponsor about changes,
- improve reliability of project plans, and
- better communicate estimates of costs, schedule and resources;
I believe they miss the fundamental basics of the problems – the root causes.
According to the Standish Group, IT projects have only a 29% chance of succeeding. You would think with the advance in technology, the development of quality processes and increase of understanding humans; we’d have a better shot of being successful. In 2003, the Standish Group estimated we spent $382 billion on IT projects in the US alone. They further stated $82 billion was an outright waste. Using the 71% failure rate, we spent $271 billion on failed projects. Maybe that’s why we need to increase the perception of success – so we can balance the books!
Based upon my years of managing IT projects (I’ll admit, not all were successes, perceived or otherwise) and experience training more than a thousand people in the art of project management, I believe the following are the root causes for IT project failures.
1. Project managers are chosen, not trained.
In my training seminars, I ask how many people actually chose project management as a career. I have had only three people raise their hands. Usually, we are selected because we are doing well in our “real” jobs and seemed to be organized getting things done. One day, as we arrive in our office, twang, we are dubbed project managers. No training.
Then I ask how many have any sort of formal training in managing projects. Regardless of the industry, the percentage is basically the same, only 20% have had any form of training. I reduce the definition of training to the ridiculous of a one hour discussion and very few additional hands go up. Only 5% have more than a day and 1% go on to be certified through Project Management Institutes’ Project Management Professional certification.
It is not we aren’t intelligent and can’t learn the ropes, but usually we learn by observing others who have gone before us. They learned the same way – by observing others. As a result, improper methods are learned and used rather than industry accepted practices. We just gitter dun – whatever it takes, nights, weekends, extra shifts, Herculean efforts – we gitter dun.
As a result, we don’t put the proper measures in place to give the information business people need. Worse, we really don’t know where we stand in our own projects. We can’t repeat our successes because we don’t know what we did to be successful. We don’t always learn from our mistakes so we are doomed to repeating them. And finally, many projects we considered successful really weren’t causing us to repeat bad habits because we believe they are good practices.
Through training, we learn proper techniques, why certain processes should be followed and the tools we need as project managers. To contrast untrained project managers with a failure rate of 71%, studies have shown using trained and certified project managers – PMPs specifically – succeed close to 75% of the time.
Root cause #1: project managers aren’t trained to do the job we ask.
2. No formal change process in place to determine success or failure.
In the CIO magazine article, someone placed a comment contrasting construction project management with IT project management. He stated IT methods are primitive to constructions processes. I agree totally.
First, construction follows a methodical, time-proven method. They work from blueprints with every detail shown. They research the site and understand what lies hidden before digging. They understand the necessary inventory of materials and labors in advance of the start date. But most importantly, they have a change process.
Once the deal is signed, any changes to the agreement require a change order with signatures. The change order details the impacts to schedule, increase to budget, amendment to the project scope, etc. Each party must sign before the change occurs, otherwise, the original plan holds. No changes are made unless the boss says so.
In IT, we take a different tack. Again, from my survey of many attendees, only three or four people stated their company had a formal change form and process. Worse, they reported changes to the project can come from any where through any channel to any member of the project team. Since many things are considered “easy,” the impact to the rest of the project and beyond is never considered. If a change is formally documented, no one dares sign it. Accountability is forbidden.
As a result, what is defined to be the project is not really the project. As time passes, changes are requested but not tracked. The project morphs and twists into something other than the original definition. As a result, the original project may have been successful using the traditional metrics, but no one can prove it because no clear definition of the project exists.
Additionally, changes come through various portals. There might be a formal request sent from the CIO to the IT project manager. Another request comes from the sales manager tapping someone on the shoulder in the hallway. A third and most insidious is the IT staffer who “sees something needs to be done, and does it” without tracking the impact to the overall project.
Solution for such a situation is two-fold: a well defined and followed project scope and a formal method for requesting changes.
Root cause #2: No formal change process which defines a single point to funnel change requests.
3. Project Expectations Not Defined In Detail
A successful project must meet the expectations of the stakeholders. Even if it comes in on budget and on time, if it doesn’t meet their expectations, it failed. Unfortunately, we don’t document the expectations. We document the technical requirements, the inventory list of hardware and software needed, select the team of implementers, etc., but we don’t seem to jot down the expectations.
If we don’t document the expectations, how do we know when we are finished? If the expectations are met, we would have success by definition, correct?
Of course, the stakeholders don’t always reveal their expectations for us to conveniently document. In fact, their expectations change over the course of the project. Even if we met the original expectations, we still fail because we didn’t meet the current list of desires.
As a result, project managers must spend a good deal of time understanding the stakeholders’ motivations, desires, intents, and rationale for the project. Periodically, he must check in with the stakeholders to verify current understanding of their needs and make adjustments accordingly.
Root cause #3: lack of understanding expectations leading to no formal documentation listing motivations, desires, intents, etc. of stakeholders.
I don’t feel it is right to simply change the perception of IT project success. To me, that’s cheating and we don’t solve the real issues. We need to change how we “do” IT project management to be successful. Proper training is key number one. I, like many, managed many projects before I was formally trained. Boy did I learn about my bad habits and improper ways of managing projects. As I instruct others these days from my lessons learned, I see the same transformation in them.
IT doesn’t have to suffer the fate of poorly run, failing projects. Solving the root causes for those problems would go a long way in better return on investments, fewer dollars wasted, and happier IT people. Once these are fixed, we can begin to work on the list from the CIO article.
Copyright © 2008, David A. Zimmer, PMP All Rights Reserved