I find myself on the meter a lot recently. As businesses deploy enterprise project management systems, I find myself more involved in the early stages of these implementations. In particular, I often find myself working with organizations on the strategic plan for deploying an enterprise project system.
If you're just getting started on an enterprisewide project management initiative, you're in good company. The most significant challenge in the early stages is not the selection of the right tool or the adoption of the ideal project management process; it's the understanding that you are involved in a significant change-management project. It's worth mentioning again that the cultural impact of an organizational change toward management by project in a centralized fashion is no small thing.
That being said, in the early stages, most of these projects involve forming a project team and asking that team to make a plan. The first debate: basic deployment strategies.
While the big-bang approach probably will come closer to the initial vision of the enterprise project management system, the phased-in approach has a good chance of gaining organizational satisfaction before the ultimate vision is reached.
Experienced project managers almost always want to take this golden opportunity to step back and review or even create a proper project management process. “Tools are a secondary conversation,” they'll say, “something to be chosen only after defining the process on which those tools will be applied.”
It's hard to argue. Adopting a productive project management process and then applying the right tool seems much more sensible than choosing a tool without a clear understanding of how it will be applied.
The proponents of this approach have a committee work on developing the right process in a sort of laboratory where it won't affect projects already in production. Once the process is finalized, the right tool will be easier to select and deploy rapidly, moving personnel as quickly as possible, perhaps even simultaneously, into the new process and new tool as defined.
As good as that sounds, there are a few inherent problems with it. First, life does not occur in a laboratory. Project personnel on the front line aren't likely to adopt something that comes out of a lab without getting buy-in themselves. In fact, the whole idea of an enterprise project management system scares the heck out of some of those people.
“I can't see that stuff making any difference,” a project manager in the telecom industry said to me recently. “I use my own system of managing a project; I’ve had great results, and I’m not likely to change so some suits in the head office can get reports minute-by-minute on what I’m doing.”
Another firm, this one in aerospace, charged a project manager with implementing a corporatewide work breakdown structure. Her quest spanned four divisions. No one further up than her manager supported the project. Personnel in the other three divisions, in the absence of management directives, listened politely but had no intentions of ever adopting her proposals. In the meantime, implementation of a project management tool to centralize data was frozen by the organization's inability to address a coding question.
Second, in these kinds of deployments, no matter how much time the central committee takes, planning lasts until the first day of deployment. Inevitably, once the process is out in the field being used on actual projects, it must be adjusted—sometimes completely reworked. So, despite all the rationale for a big bang, get the process right before deployment, I’ve got to vote with the phased-in approach.
A phased-in approach starts the actual deployment much quicker with a smaller group of people or a subset of the total number of projects. In this scenario, the time spent on the global process is minimal. The idea is to start a system that looks like it will be able to handle the needs of the whole organization and start producing some benefits with it quickly.
Because the process is poorly defined in such a deployment, you'll have some teething pains that will require more effort in the early days. You will have to budget more time, more assistance and maybe even more money for the early adopters of the system. But these amounts still will be a tiny fraction of the cost of adopting the entire system in a big-bang approach. You'll need to pick strong early adopters because you'll be developing the process on the fly through the first pilot projects.
The great news about this plan is that management can start seeing results early. More assistance in the early days almost makes this a certainty and winning more management support makes a world of difference as you work through the organization deploying to more and more people.
There are decided advantages and disadvantages to each approach. While the big-bang approach probably will come closer to the initial vision of the enterprise project management system, the phased-in approach has a good chance of gaining organizational satisfaction before the ultimate vision is reached. It is also true, however, that the big-bang approach is much more likely to go absolutely nowhere, stalling somewhere in the definition phase, without getting people to agree on how to move forward even to the first step. The phased-in approach starts almost immediately and, thus, the company has a much higher chance of realizing some returns on the investment of time and energy that any such project involves.
Either way, remember, you're dealing with change, and change invariably causes upset, even when it's ultimately a change for the good. Plan for that distress, and you've got a good chance at making your enterprise project management system a success. PM
Chris Vandersluis is president and co-founder of HMS Software, based in Montreal, Canada. He is a member of PMI and the American Association of Cost Engineers. He has appeared in publications such as Fortune and Heavy Construction News and is a regular columnist for Computing Canada magazine's project management column.
