We have observed four classic impetuses for EPM implementations that lead to failure with such regularity that you should consider them avoidable if only because they’re recognizable. Does your enterprise project management implementation resemble any of the following four scenarios? If so, take steps now to correct your course.
Boiling the Ocean
While it is true that Microsoft produces great software, it also seems to produce lots of buzzwords, acronyms and expressions almost creating a language of its own. One of the more catchy phrases we heard during visits to the Redmond campus last year was, “We can’t boil the ocean” paraphrasing the simple wisdom that you should not bite off more than you chew. If any company could boil the ocean, one would think Microsoft would stand a chance, but Microsoft is smart enough not to attempt it. We must say, though, that Microsoft’s 2007 product releases, collectively, are probably as close as any company has come to boiling the ocean.
For the rest of us, it is an appropriate reminder that one of the least successful approaches to EPM deployments is to go big and go fast. It rarely works. While it is quite all right to aspire to such heights for your EPM deployment, starting with the notion that you are going to launch with hundreds or thousands of users is, to put it mildly, ill advised.
Remembering that EPM technology changes the way people work and has serious psychological impacts on the organization, it’s always best to start with a proof of concept/pilot. Of course this is sound advice for any technology implementation but particularly poignant for technologies with any magnitude of organizational impact. Implementing EPM is much more akin to rolling out a new ERP system than it is to rolling out the latest version of Office. Although the 2007 Office applications really have changed substantially, you’re much more likely to succeed in rolling out the latest version of Microsoft Word to 100,000 users than you are likely to succeed in rolling out EPM to 100 users. Once past the initial testing and compatibility checks the Word rollout might require a bit of floor support for your users; but implementing EPM requires building new competencies and engraining new behaviors for both management and staff members alike.
In selecting your pilot group, stack the deck for success. Keep it contained to a group of people who are most likely to embrace the change and succeed. Look to engineer small wins and celebrate them when they occur. Market your solution to your organization by advertising your wins and encourage your pilot participants by giving them a voice in the system design from the very beginning and by recognizing them for their contributions. Do not launch your new EPM system with the largest project in your portfolio; rather select a smaller, more resource-contained initiative on which to cut your EPM teeth.
One Big Project
Twenty weeks into your $40 million ERP initiative is not the time to decide that you need new project management controls for your project and that implementing Project Server is part of the answer. While your attempts here may end up succeeding under the auspices of desperation, one project, no matter how large or complex, does not justify an EPM tool implementation.
To begin with, if your project is already off to a chaotic start, it is rather unlikely that you can carve out the time necessary to take on EPM as a project as well. Rather than one failed control initiative, you will now have two. Further, if your organizational maturity has allowed you to progress this far down the road to disaster, chances are you will not be able to change that culture in time to realize EPM benefits on your current project. Instead, you run the risk of distracting your attention from your other full-time jobs.
If you want an EPM initiative to succeed, you should introduce it gently, not as a crisis management solution. The best you can hope to achieve applying the technology as an after-the-fact solution is to add a degree of transparency to your project as you will not have the time or the organizational bandwidth to adopt the behaviors and management commitments necessary to benefit fully from an EPM initiative.
Because your organization’s underlying bad habits are not going to change with this approach, the benefits you can realize are not going to be significantly important to your stakeholders in the midst of the larger crisis at hand. Such is the way for companies that run their projects through crisis management. Your deployment will be useful only to a handful of users.
Methodology Overload
“Methodology Overload” implementations are those that imagine that one can spread methodology adoption across an organization like cream cheese on a bagel. These typically fail in the earliest stages. The benefits of project management methodologies and controls are so obvious to the proponents that nobody among indoctrinates can imagine that there could ever be a hint of organizational resistance to them. Why plan for the impossible? Instead of organizational change, these initiatives focus on methodology and miss their marks in so doing.
Characteristic of these deployments, committees pore over drafts and rewrites of the company’s new standards for project management inevitably leading to a document release that we can only describe as the My Company PMBOK. In these situations, methodology proponents spend weeks or months rewriting PMI PMBOK guidance to fit their corporate vernacular all the while thinking that they are achieving buy-in because they are working in committee.
Ultimately, the work product ends up tossed aside because it is too technical and voluminous to interest or guide anyone except for the choir that wrote it. For the authors, it becomes a prayer book and nothing more. Because the prescribed procedures are so cryptic in nature, many in the organization see this attempt at guidance as another furtive effort to undermine their status quo.
In our opinions, the greatest opportunity that EPM tools present to most companies is to introduce organizational controls that follow intelligent methodologies without the need to indoctrinate the organization at-large into a complex management science. The goal is to embed control intelligence into the process and process controls rather than providing a written prescription. This requires a primary focus on the controlled process and less focus on the controlling process. Unfortunately, most methodology-overload projects are lost in theory and tend to focus on the controlling process only.
After many years of working with numerous organizations, we have yet to see such a document received with acclaim and excitement by a general audience. At times, this is the result of a shortsighted initiative, while for others it is the result of organizational constraints. In either case, it is not a promising way to launch an EPM effort.
Use It or Lose It!
When an IT department serves up EPM to its business units as part of a “technology buffet,” willing diners will always line up for a free meal. In companies where this occurs, the buffet offering often accompanies an ill-defined internal push for project management. There might be a corporate improvement initiative underway that is giving lip service to process improvement, efficiency initiatives, or quality management solutions to bolster or encourage take-the-plunge approaches. Sudden executive interest might have an impact at budget time. For all the positive motivating factors one can identify, mostly this type of misguided deployment occurs because the technology is too accessible.
The licenses came with our Enterprise Agreement so we might as well use them, is a typical rationale. This, too, smacks of the build-it-and-they-will-come mentality that so often characterizes the boil-the-ocean deployment, but its poison is much more insidious as the buffet attendee is ill prepared for what comes next. Typically, it takes a bit of wrangling for a business unit to get a new software application sanctioned for use, and this wrangling comes in the form of due diligence such as a cost benefit analysis, which engenders a more solid footing to begin with. In the case where the application is pre-sanctioned, these obstacles and their natural sanity checkpoints do not exist.
The lowered barriers typically include a much less rigorous challenge to the requesting organization resulting in little or significantly lower due diligence overall, and a high rate of deployment failure.
The diligence due in this case is the organizational commitment and a process to follow for success. In many cases, EPM appears on the buffet table with little or no regard given to these critical elements. Very often, the IT team offering up the application does not understand it, and often has no intention of internalizing it as a standard for itself and therefore no intention of building the required competencies.
Somebody needs to make a competency commitment, or deployments fail rather quickly, but in these cases, it is up to the implementers in the business unit to rudely discover this fact and quickly correct midstream. Sadly, this is a difficult miscalculation from which to recover.
Next time: Strategies for EPM Success
This article is an excerpt from the book Implementing and Administering Microsoft Office Project Server 2007 by Gary Chefetz and Dale Howard.
