Deploying an enterprise pm system is the current hot thing – What’s more effective? Creating the perfect process then deploying across the entire enterprise in a Big Bang or phasing-in a less mature process bit-by-bit?
I find myself on the meter a lot recently. It’s not something I’ve done for quite some time but the trend of businesses of all sizes to deploy enterprise project management systems has our staff asking me more and more to get involved in the early stages of these implementations. In particular I often now seem to find myself working with organizations on the strategic plan for deploying an enterprise project system.
If you’re just getting started to working on an enterprise-wide pm initiative, you have lots of company. One of the first things you’re going to have to be clear on is that most significant challenge in moving forward in the early stages is not the selection of the right tool or the adoption of the ideal pm process; it’s the understanding that what you are involved in is a significant change-management project. While I’ve talked about this before in this column, it’s worth mentioning again I think that the culture impact of an organizational change towards management by project in a centralized fashion is no small thing.
That being said, the way most of these projects go in the early stages seems to start with the striking of a project team and asking that team to then make a plan. The first debate is almost always when I seem to arrive and that’s on basic deployment strategies.
People who have been around the pm game for awhile will most often 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. I’ve been in the pm software business now for almost 20 years and I’d have to say that adopting a productive pm 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 plan would have a committee work on developing the right process in a sort of laboratory where ideas could be worked on without affecting the projects already in production. Once the process was finalized, the right tool would then be easier to select and the deployment would now be done in a rapid fashion, moving personnel as quickly as possible, perhaps even simultaneously into the new process and new tool as defined.
Well, as good as that sounds, there are a few inherent problems with it. I’ve been in several organizations now watching people attempt to do this very thing and here are a few of the challenges they’re facing.
First of all, life does not occur in a laboratory. The project personnel who are working in 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 pm systems scares the heck out of some of those people.
Recently while talking to a project manager in the telecom industry I asked what he thought of the changes that were reported to be coming. “I can’t see that stuff making any difference,” he said. “I use my own system of managing a project; I’ve had great results and I’m not likely to change the way that I manage so some suits in the head office can get reports minute by minute on what I’m doing.”
While I was at another firm, this one in the aerospace industry, the person in charge of the enterprise pm system deployment tried to explain her difficulties in getting a corporate-wide WBS adopted. A few short questions later and it had become apparent that the scope of people involved in her quest spanned 4 divisions of the firm. She had no one supporting the project from further up than the manager of her own division. Personnel in the other 3 divisions, in the absence of management directives from their own managers, were being polite in listening to her but had no intentions of ever adopting her proposals. In the meantime, the implementation of a pm tool where data could be centralized was paralyzed with the inability of the organization to get over this coding question.
One of the other phenomena I’ve noticed in these kinds of deployments is that no matter how much time the central committee spends trying to write the ideal pm process, the plan lasts until the first day of deployment. Inevitably, as soon as the process is out in the field and seeing the use of actual personnel on actual projects, the process needs to be adjusted; sometimes completely reworked.
So, despite all the evidence from my purist sentiments that cries out to get the process right first before deploying in a big way, 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 get a system going 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 will still 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 as you work the system through the first pilot projects.
The great news about this plan is that management can start seeing results early. The presence of more assistance in the early days from the deployment team almost makes this a certainty and getting 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. I think it’s probably true that the Big Bang approach is more likely to get closer to the initial vision of the enterprise pm system. The phased approach has a good chance of reaching some level of organization satisfaction and thus complacency before the ultimate vision is reached. Yet I think it’s also true that the Big Bang approach has a much more likely chance of going 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 and you’ve got a good chance at making your enterprise pm system a success.
