“Resistance is futile” was the battlecry of the evil Borg from Star Trek. Sometimes I’m sure there are PMO’s who wish they could be as convincing to fellow colleagues who are resisting the deployment of enterprise project management and enterprise project management systems.

Getting the job of deploying an enterprise project management environment is not the best news for some people who have to complete that project within an organization where there may be a great deal of reluctance to change how projects are managed. Almost every week I’m in some meeting where a frustrated project manager is asking my advice on how they can convince the rest of the organization to embrace the new project management thinking.

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 the purchaesd 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. These things are much more rare. 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 a 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 comlex 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 helpless? It certainly is not. If you have the role 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 enteprise 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 have 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 perosn 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 thew 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.

Whenever I am involved in the deployment of an enterprise-wide system I’m reminded of an analogy attributed to Buckminster Fuller (You remember Bucky. He’s the fellow who came up with the idea of geodesic domes.) Anyway, the story is about turning a ship. You see, when a ship is very large, say the size of a super-tanker, the size of the rudder to turn it must be correspondingly large. The problem is, that a ship such as this underway causes so much water pressure on the rudder, that the force required to push it against the water to turn the ship is incredibly large. So, someone very clever invented the “trim-tab” A trim-tab is a little rudder on the rudder and it seems that if you push that rudder in the opposite direction you want to go, the main rudder can be moved outwards with almost no effort at all.

Ok, cute story, but what does it have to do with project management software and enterprise systems? Well, everything.

The biggest issue with deploying an enterprise system is not the perfect selection of functions against requirements, it’s changing the corporate culture. For anyone working in a medium to large sized organization, you know that comparing the intractability of a corporate culture to the momentum of a supertanker is not at all inappropriate.

Over the past few years I have seen many, many fine individuals break their spirit over this issue. They know they’ve picked a product that will answer their firm’s needs but are unable to get it implemented throughout the organization. No matter how much force they mustered, it was never enough to ‘turn the ship’. The selected software ends up either completely abandoned or being used just by the core implementation team, another element to add to a fractured systems environment.

In those organizations where an enterprise project control system has been successfully implemented, inevitably, the corporate culture was changed a step at at time.

Operational procedures are business’s ‘trim tabs’ for corporate change. Now, lest you leap forward and think, ‘Great, tomorrow I’ll get started on a new procedures manual with hundreds of procedures to make people comply with our new corporate culture.’ or that you think you can mandate a corporate culture change by simply making a procedure called “change your cultural habits”, think again.

The changes that will be most effective will be insidious yet impactful. I was recently privileged to be in a conference session with a number of experts in the deployment of enterprise-wide project systems. A couple of their comments are worth noting. One of these experts described how their organization had designed a “knowledge base” of lessons learned on past projects. For some time the knowledge base had been established yet no one ever seemed to have the time to contribute to it. If there were lessons being learned, they weren’t being made available to future project managers.

The expert in this organization (you’d recognize this three-letter firm if I mentioned it), decided on a small change in procedure. Inside the contract for the project management consultants, a new line was added, identifying the contribution of lessons learned to the knowledge base as a deliverable part of every future contract. Hmmm, guess what? Suddenly every project management consultant seemed to find some new time. No contribution, no final payment for the contractor. This wasn’t a big corporate decision, Moses was not required to come down the mountain with stone tablets, it was a little one-line change to a contract template that turned the ship… a trim tab.

The other expert in this session had project managers who were not contractors, they were employees. Holding back payment in this scenario could not be one of the options. In this firm, a similar impact was made. On the project manager job performance review form, a new line was added. Project managers were now to be graded in their contribution to the project management process. Surprise, surprise, within a few months, project managers seemed suddenly interested in a process that they would have been hard pressed to identify in the past… trim tab.

What I like about both of these examples is that they started surreptitiously. All too often, when organizations attempt to implement a system company-wide, it starts in one of two ways. If the system originates from the mid-levels of the organization, then it rarely comes with the authority to deploy with every department and every user and often stalls within a close-held group. If the system originates from a high-level of the organization, then all-too often it comes with too heavy handed an approach. While upper management almost always has the authority to impose a structure, if it tries to impose a change in culture without considering the human impact, it runs the risk of creating “covert saboteurs”, staff who pay lip service to the new system yet make every effort in the background to stick to the old ways.

Culture change can be a sensitive thing. If imposed too quickly or too drastically, employees may feel threatened, their familiar world turned upside down. The most impactful changes are usually those which sneak into the system and the best way to deliver those changes is through small changes in procedures. Changes that at first glance don’t seem to change anything significant.

If you’re interested in change in your own organization, start looking for those trim tab opportunities. Ask yourself what change in function or practice would result in behaviour that would contribute to the deployment of our enterprise-wide system. Then, before implementing that change, ask yourself what the likely reaction would be to implementing that procedural change. If the reaction is likely to be major, you’ve not found a trim tab, you’re trying to push the rudder itself.

Of course, sometimes there’s simply no choice but to go with the brute strength approach. For example, organizations faced with a shortening calendar before the year 2000, find themselves implementing complete overhauls or replacements of core organizational systems. Where changes might have been better implemented over time, these firms must drive quickly, pushing the system in where it is required. If this is the scenario you’re facing, then other methods can mitigate the potential negative impact. Skilled ERP implementors use focus groups and familiarization sessions in part so that nervous recipients of the new system can express their concerns and have their issues answered by people with the control to deliver answers.

No matter what your situation, keep looking for those unique and powerful opportunities to enhance the situation in your own organization through the smallest of changes, the trim tab.

In 1994 I wrote an article outlining a disturbing trend in project management systems deployments.  At the time, there was a significant movement away from large-scale project management systems to PC-based systems.  The movement had really started in the mid-80’s with the rapid adoption of the PC as a work tool but the release of Windows had spurred the sale of project management systems as never before.  The original high-end project systems of the late 70’s, I wrote, cost in the hundreds of thousands of dollars and clients thought it quite reasonable to spend that much again on training and configuration.  The problem was, the systems of the 90’s cost only a few thousand dollars or less and the general reaction of clients I met was to spend an equivalent amount of money on training comparative to the value of the software rather than the training that had always been required.

I bring up the subject because of the recent advances into the enterprise project management domain of Microsoft.  There is a newfound interest it seems in bringing the enterprise together to manage projects and Microsoft is at the very forefront of that interest.  With the release two years ago of Project Server 2002 and the release of Project Server 2003 last year, Microsoft delivered a product that can be deployed as a enterprise project system.  What’s fascinating about the release of this product into the marketplace is the way people are going about using it to deploy Enterprise Project Management.

First of all, there’s no question that the concept is desirable.  Virtually everywhere I go from the smallest to the largest organization, there is a need to bring project information together and to strive for making better decisions about projects across the organization rather than project-by-project.

The legacy that Microsoft carries however isn’t helping it.  Microsoft has become known in the application business as a company that provides low cost project management software to the individual.  In virtually all of Microsoft’s applications, the expectation is that you’ll be able to quickly install the product yourself, configure it immediately and then be able to start producing results instantly.  The Windows versions of Microsoft Project all held to those principles.

Now, along comes Project Server and the ability to work across all projects at once and to group projects by portfolio and to collaborate with team members and PMO personnel alike.  Sounds like a match made in heaven, yes? 

Sorry, no.

The issue is the same as in 1994.  When considering the deployment of Project and Project Server, many clients bring their legacy of experience with Microsoft to the table.  In a recent conversation with a very high-tech firm, I helped scope out a deployment plan that called for about 4 weeks of configuration work including mapping processes to Project and then another 3-4 weeks of training for the 200+ personnel involved in projects who would have access to the tool.  Of the total, only about 2 days were involved with installation.  The project manager was stunned.  “I had figured on 3 to 4 hours,” he replied.  “with maybe a day or so more of training.” 

We’ve now seen numerous scenarios where an organization does a minimal epm effort and ends up having to go back and do it again, this time with less credibility with management.

The need for configuration and training shouldn’t be a big surprise.  When the same project managers are asked about any other major enterprise system such as ERP or CRM, they acknowledge the extensive effort that will be required to implement change.  Perhaps it’s the shoemaker’s children going barefoot syndrome where project managers can’t seem to apply the same logic to their own systems.

Maybe the solution to the problem is much simpler.  We should ask Microsoft just to add two zero’s to their project system pricing so we can take it more seriously.

Years ago I had the occasion to attend a fascinating seminar about getting what you really want in life.  As an object lesson at one point, the leader offered to dissipate the headache of anyone who had a headache and who wished to get rid of it.  I won’t bore you with the procedure although I did see the demonstration done multiple times and with 100% success each and every time.  I was reminded recently of one of the key elements of the demonstrations which, I think, is pertinent to anyone doing an enterprise project management systems implementation.  Once a willing volunteer had been selected, the leader made a special point of asking them if they were willing to have their headache disappear.  This wasn’t a casual question, they said.  This was critical to the demonstration’s success.   The volunteer was asked to think about it for a moment to be sure they were willing to rid themselves of this headache.

I’ve been thinking lately that I should be doing the same thing with some of the larger organizations I consult about deploying enterprise project management.  Given our business, we’re almost always talking about the more technical aspects of such a deployment; installing epm and enterprise timesheet systems and configuring them to match a corporate epm process.  The problem seems to come up time and time again as we get near the end of the deployment and the system and/or process is about to go live.  Suddenly there is a burst of resistance from different sources and a pause as the epm project team considers what they’ve gotten themselves into.

It’s not like epm systems and epm processes don’t work.  They do.  There is plenty of evidence in case study after case study.  The problem is more that these projects are inevitably considered technology projects rather than change-management projects and, despite the advice of everyone involved, changing behaviour and culture is infinitely more difficult than installing software.

Moving an organization to work together in any aspect of its business is a challenge.  This is certainly so when we talk about project management.  The benefits to management of having data all gathered together seem obvious but the costs are not always apparent.  There is no question that deploying epm will always be a trade off. 

Ok, that sounds perhaps strange coming from someone who has been an evangelist for epm for 20 years or so but it’s true nonetheless.  Sharing resources makes for a great demonstration and, in a perfect world, seems like an obvious solution but there may be a penalty as project managers who have been able to successfully hoard resources by flying under the radar are now pushed to work at the same level of effectiveness as less efficient project managers. 

Having everyone see global data may seem excellent until you find that there are some who will use the opportunity of more data access to spend more time lobbying by using the data of other project managers than working on their own. 

Left unmanaged, it is certain that an epm system has the potential to make an organization less efficient rather than more.  John Chambers, the CEO of Cisco Corp. had a study commissioned where the effects of automation and the effects of process change were studied.  In some cases, the study found, automating then changing the process actually caused decreases in efficiency of up to 9%!  On the other hand, adopting a new process and then automating it caused increases in efficiency of up to 21%. 

The lesson is really one for me and people like me who work with organizations who want to implement enterprise project management.  When an organization says they’re ready to solve their problem, I’ve got to ask: “Are you sure you want the solution?”