Where Could We Go Wrong?
If you have just been assigned such a project, then the first thing to know is a few of the pitfalls.
I talk to a lot of people about project and timesheet systems, given the business I run, and one of the most common pitfalls has to do with enterprise project management software. "If you build it, they will come" is a common theme from those purchasing such software. I have met with numerous CIOs who have already concluded the purchase of a centralized project management tool and then call me to ask if I can "make it work" for them. I have to ask why they purchased the product. The answer inevitably is "Because it will help fix our project problems". I have to ask if there is a design for how this particular tool will fix those problems, if there is a list of the 'project problems', if there is a process in place on which to base the use of the new tool. Even among very educated people, there is often an excessive dependence on technology to fix project management problems. A big pitfall then is thinking that the purchase and installation of some project software will do all the fixing for them.
A second significant pitfall is the reluctance of some executives to take a leadership role in the deployment of an enterprise project management environment. "Let's manage by consensus," goes the theory. Consensus is a wonderful thing if you don't like conflict. A decision is left before a group of the rank and file. They won't take a vote and choose based on the majority. They won't choose a leader and do what the leader decides. They won't have a leader imposed on them by a higher authority and do what that person directs. They will discuss, debate and eventually arrive at a decision that the whole group can agree on. There will be no conflict because everyone will have agreed. This may work well when picking a color for painting a room, but I can tell you from experience, it's rarely successful when designing project management software. The most likely result is that the design will have accommodated every little request of each and every user to a point that the design is so complex as to be undeliverable or wildly beyond the budget. Or, that there is no consensus because of the investment members of the group have in avoiding change. Consensus is often a way for executives to avoid commitment. Turn the problem over to the employees and ask them to come up with a plan that everyone agrees on. It avoids conflict to be sure, but it also avoids creating a process that will make the entire organization more effective.
The last pitfall I'll mention here is to avoid the Fifth Column. The Fifth Column is a term that comes from the Spanish Civil War circa 1936 when General Mola claimed to have a fifth column of military in Madrid while he was attacking with four columns from outside the city. We tend to use the term these days to refer to a clandestine element within our own organization that says it is our ally but, in fact, is working to subvert our objectives. Some executives tell me "our people will comply if I darned well tell them to," when I ask how we will deal with support within the organization for an enterprise project management environment. But there are a lot of "Fifth Column" techniques for avoiding doing so. The most common, and for me, the most difficult to deal with is the middle manager who nods his or her head in agreement at every single meeting but then will take no action to support the project in any way.
A successful plan
Is it hopeless? It certainly is not. If you have the job of enrolling the reluctant enterprisers, there is a lot you can do. Here are some of the most successful techniques we've seen:
First make a plan. I know, I say that in some way in almost every article I write. The reason I say it so often is that it's still the most common error I encounter. People often end up starting an enterprise project management project without a solid plan. They don't "ready-aim-fire". They "fire-fire-fire". They are in action almost instantly, choosing an enterprise project management product, hiring skilled project managers, responding with action to management's desire for more decision making tools. Then everything that happens subsequently is a reaction to not having had a plan in the first place. So, make a project plan. And, do all the things you'd normally do on any other project on this one too. That might mean creating a charter, getting a budget, having a schedule, choosing some milestones and so on.
Secondly, get some friends in high places. I've been around a number of EPM deployments lately where there is no management support at all. In one meeting, the vice-president who had started the initiative had deliberately avoided any meetings with the people involved because they didn't want to interrupt the consensus building of the group. In another situation, the senior executive didn't want to attend key decision-making meetings because they didn't want to leave some employees who were not invited feeling like their fates were being decided in their absence.
It's critical to have the support of some or all of senior management. If you don't then the chances of success of the project drops quickly. Think of it like this. The project management process in most organizations will affect almost every part of the organization. Doesn't it make sense that the senior management should play a significant role in redefining that process? The project management process for many organizations includes having an executive sponsor to shepherd the project through the senior management ranks. This project deserves the same.
Once you've got your plan, communicate it. Then do it again, and again, and again and again. Communicating how the plan is going to work, is working so far and how it worked yesterday will all go a long way towards enrolling those who might be worried about how the new enterprise project management environment will affect their jobs. Since EPM is always an evolving and adapting process, there should always be a little time reserved for communicating about it.
While some senior managers may believe they can come down and knock some heads together to get compliance, it is rarely successful. So, think in terms of more carrot and less stick. Instead of imposing big penalties on non-compliance, why not look to how you can improve the return on investment of each person who interacts with the new EPM environment. What can you give them that will make their life better and more effective?
Finally, try to have your plan deliver bite-sized pieces. Getting started small and gradually expanding the new process is inevitably more successful than trying to create a massive plan and delivering it all at once. There are a lot of reasons for this but one of the most important is that the very design you're trying to create will be changed by implementing it. The needs and interests of the organization will evolve, and changing such a fundamental process might have it evolve significantly. If you're deploying your new EPM system bit by bit then you can adapt each parcel of it to the changing needs of the people it must serve.
On Star Trek, the Borg were never defeated head-on with a brute show of force. But they could be overcome with finesse, using guile, creativity and perseverance. Those qualities will hopefully serve you well as you work on enrolling your reluctant enterprisers.
Don't forget to leave your comments below
Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal's McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI's PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University's Executive Institute. He can be reached at firstname.lastname@example.org