Project Management

Showing the value of your PM methodology

One of the fundamental problems in project management is how to show its quantitative value to your company. Here are some of the reasons that it's tough to pin down exactly what project management contributes to the bottom line.

TechRepublic columnist Tom Mochal receives dozens of e-mails each week from members with questions about project management problems. He shares his tips on a host of project management issues in this Q&A format.

Question
We recently implemented formal project management processes and a project management office into our organization. My manager asked me to quantify the value of the methodology to our organization. On the surface, this seems like a reasonable request. We are a large company and have a lot of projects going on. However, the more I look into it, the more it’s like trying to hold a cloud in your hands—you just can’t do it. As a veteran of project management, do you have any advice for trying to show the quantitative value provided by a project management process?

Answer
You’ve asked a fundamental question about project management methodology. Your analogy of holding a cloud is a good one. From the distance, it seems like there should be something there. However, the closer you get, the more vague and transparent everything becomes. Since you have looked into this issue, you probably have some ideas as to the cause of this frustration. In my opinion, there are a number of factors that make this difficult.

You can’t precisely compare projects before and after
All projects are unique. Because of this, you can’t make direct apples-to-apples comparisons of what projects looked like before the use of project management processes and after the fact.

You’d like to say that it took us X hours to do a project before, and now it takes Y. However, two projects never give you the same context in which to make this comparison. You may be able to make some general statements by comparing projects with similar characteristics. However, most companies don’t keep any historical records of project characteristics and costs to use in this type of comparison.

There’s a lot of other stuff going on
The rollout of project management processes in a large company requires a fair amount of time to be successful. In fact, it may take a few years in a large company before everyone is trained and using the new methodology. Of course, no organization can stand still while a lengthy cultural change is going on.

The problem, then, is that it’s hard to tell how much impact the project management initiative has on the organization vs. other factors that are coming into play at the same time. Over a couple of years, you find that new tools are being introduced, human resource changes are occurring, reorganizations shake up teams, and other culture change initiatives are vying for focus. It’s hard to isolate what factors are making projects run more smoothly.

You do not have a basic and consistent unit of work
The fact that projects are unique wouldn’t be a problem if we could factor them down into some basic units of work. In other words, if we could say that one project without project management required 25 units of work, and a second project with project management required 40 units of work, we could easily determine the effort and cost per one unit of work and then compare these numbers.

You can create this unit of work by initiating function-point counting in your organization. However, most companies do not count function points and don’t plan to. Therefore, determining relative size and complexity of projects to any degree of confidence is problematic.

Things may be a little worse before they get better
The introduction of structured processes into an organization might well result in some short-term incremental costs before the long-term value materializes. For instance, when the methodology is new, you may pay for customizing it for your organization. You also need to invest in training and perhaps some ongoing coaching.

In addition, when a project team uses an unfamiliar process for the first time, there’ll probably be a learning curve. If the project is long enough, the long-term savings could outweigh the learning curve. However, if the project is short, the participants may tell you that it took longer than it would have if the new methodology were not in place.

This is not surprising. The overall value of the project management processes must be measured over time, since much of the value will kick in through the reuse of the common processes. The first time you use an unfamiliar project definition, it may take you longer to define and document the work. However, the second time you use the same project definition, you would expect that the familiarity would result in the project being defined much more quickly.

It’s a start
You asked me if I had some ways to measure the value of introducing project management disciplines into an organization, and I spent a lot of time telling you why it cannot be done precisely. However, given the limitations that I just discussed, it’s possible to create some algorithms that can approximate the value of project management processes within the organization. Stay tuned for the next column, where I will provide some concrete ideas for how this can be done.

Tom Mochal is president of TenStep, Inc., a project management consulting and training firm. Recently, he was Director of Internal Development at Geac, Inc., a major ERP software company. He’s worked for Coca-Cola, Eastman Kodak, and Cap Gemini Ernst & Young. Tom has developed a project management methodology called TenStep and an application support methodology called SupportStep.

Editor's Picks