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.
