The Role of the Project Manager on a Failing IT Project

Originally published on erp.com

My recent book review on Slashdot prompted quite a few comments on many topics related to IT projects. Some of the more interesting ones concerned the role of project managers (PMs) on these endeavors. I think back to a long-standing debate that I have had with many friends and colleagues about what, if anything, a PM can do on an ill-conceived project. To this, there are three distinct views.

Superman

At one extreme, there are those who feel quite strongly that PMs are ultimately responsible for the fate of the project. They cite the fact that many client end-users on implementations have “dotted line” reporting relationships to PMs during these types of projects. What’s more, the sole focus of a dedicated PM is the project at hand and they cannot claim that their “day jobs” interfere with their ability to move projects forward. Finally, PMs have access to steering committees, project sponsors, and other senior folks in the event that they have to flex some muscle. Given all of this, projects should be successful.

Sheep

At the other extreme, some believe that PMs are merely extensions of the project at hand. Under this view, PMs are not …

My recent book review on Slashdot prompted quite a few comments on many topics related to IT projects. Some of the more interesting ones concerned the role of project managers (PMs) on these endeavors. I think back to a long-standing debate that I have had with many friends and colleagues about what, if anything, a PM can do on an ill-conceived project. To this, there are three distinct views.

Superman

At one extreme, there are those who feel quite strongly that PMs are ultimately responsible for the fate of the project. They cite the fact that many client end-users on implementations have “dotted line” reporting relationships to PMs during these types of projects. What’s more, the sole focus of a dedicated PM is the project at hand and they cannot claim that their “day jobs” interfere with their ability to move projects forward. Finally, PMs have access to steering committees, project sponsors, and other senior folks in the event that they have to flex some muscle. Given all of this, projects should be successful.

Sheep

At the other extreme, some believe that PMs are merely extensions of the project at hand. Under this view, PMs are not magicians. No PM can make four completely different systems talk to each other, singlehandedly cleanse years of inconsistent data in a legacy system, or convince reluctant end-users to get with the program. In short, PMs have limited impact on a project.

Limited Influencer

Those who take the middle ground believe that PMs matter, but only to a certain extent. A good PM knows when to delegate, when to play the good or bad cop, when to micromanage, and when to be “hands off.” A good PM cannot prevent a train wreck but his or her toolbox will allow for optimal outcomes under suboptimal circumstances.

My Take

In Why New Systems Fail, I detail four different types of IT project failures. The most severe—the unmitigated disaster—cannot be saved by Jack Welch himself. Sorry, Jack. I tend to view PMs are important but not omnipotent. They are certainly not the most critical factor in a project’s success. The buy-in of senior management, the architecture chosen, and the resources committed to a project are (among others) higher up on the list of reasons for a project’s success or failure.