This movement is also prevalent throughout the software application industry. There are books on how to deploy an enterprise project management methodology, and how to install and use enterprise project management systems to support that methodology. These books are heavily encouraged by software vendors like Microsoft who talk internally about scale. “What’s scale?” you ask. (It is the strategy by which)the software publisher can empower several million people to successfully purchase and deploy their epm product).
So, is this a problem? Am I saying that Do-It-Yourself is bad? No, and No. Think about creating your own patio deck. You can go to the local hardware, pick up a book and a DVD, with detailed plans along with the cement, wood, screws, nails, tools and varnish. What you can’t pick up is the real life experience. If you’ve ever done this kind of project, you know it’s not as easy as the book or the DVD portends. The most common challenge? Finding you did something out of sequence or improperly measured and that you’ll need to do that part again.
People come at their deck project in one of three major ways:
- They do it completely by themselves. They read the book, they make do if they must and they correct if need be. (This is currently by-far the most popular DIY method)
- They do some of it themselves. You read the book, but you call in the second uncle, twice-removed, who is in the home renovation business and you lean on his expertise. He drinks a lot of beer while you do a lot of the legwork but in the end the deck looks pretty good.
- They hire a company to build the whole deck and watch from the outside.
If we’re talking about the deployment of an enterprise project management system then the analogy holds together pretty well. We see many people attempting to do this on their own by reading a book or looking at some online documentation. But there are a few things that people don’t often think about when considering the deployment of an enterprise project management system. The most important of these is that an epm deployment is a change-management project rather than a technology project. The installation of an epm system is usually accomplished in under a week. A complete deployment for, say 300 users is between six and 12 months. What’s the difference between one and 26 to 52 weeks? Lots of work!
Think about it. You’ve got to get the system working. Fine. But what about how people work now? Projects are underway, aren’t they? You will need to speak to those people and a) find out how they are managing their projects now; b) adapt your methodology to include the features they’ve designed into their Excel spreadsheet or whatever they’re using; c) inform these people how the use of the new tool will include what they’ve done and how it might be represented differently; d) enroll these people into using the new tool even though it will be different or (worse) that it may not include all the features they wrote into their own thing ; e) write a methodology that includes all the adaptations and new ways of working that you’ve designed; f) customize, configure or change your epm system to empower that methodology and finally; g) train those people in both the new methodology and the new system.
Still think this can be done in a week? It can’t. Even for small deployments.
This is, by far, the largest pitfall we see in epm system deployments. It’s perhaps not a huge surprise. In the earliest epm systems in the 70s and 80s, the cost of purchasing an epm system would easily run into the hundreds of thousands of dollars. If you were buying such a system, it was completely reasonable to spend an equivalent amount of money for consulting, training and implementation.
With the cost of enterprise systems dropping to a tiny fraction of these early prices, the thinking on services has, unfortunately, dropped proportionally. We regularly get calls from organizations asking if we can complete an epm system deployment in three or four days. Which, of course, we cannot.
What about doing it yourself? Can you learn enough to do this kind of project yourself? Well, of course you can, but not everyone thinks about the implications. Remember the deck! First, you’ll need to climb a learning curve on epm system and epm methodology deployments sufficiently to be successful. Anyone can do this of course, but you’ve got a big handicap if you’re climbing this curve internally: You’ve only got one deployment on which to get practical experience; the main one. Can you still do it? Sure, but the most common pitfall is misestimating the height and length of the learning curve and if you do that, you’re biting off a lot of investment that you can only amortize over one deployment. Companies that specialize in this work can amortize the costs of training a consultant over many, many deployments.
When you bring in an external consultant, you get a few advantages that are hard to find in books. That person inevitably comes with experience in the same kind of project in other places. That includes the good experience and the bad experience and around our office, we value the bad experience very highly. Someone asked me a while back what characteristics I would look for in a consultant that would make me feel confident in their abilities. I responded that one thing that would be highly valuable would be someone who had been in an epm deployment that went badly from which they had found a way to recover. This was a surprise but I believe that the in-the-field experience of overcoming a challenged implementation teaches you more than any book ever could. Aside from avoiding obvious pitfalls, you’ll also get an insight into how other companies have tackled specific project management or project management system challenges, and this may lead you to tackle a solution in ways you never considered before.
So, should people throw away those self-help books? Absolutely not. Our recommendation for this kind of project is to take the middle ground. Call in a consultant early to at the very minimum, help with scoping the project. This is often an eye-opener for management. If the project goes ahead, keep an expert on tap. Have them there for the critical phases you’ve identified together, and to help avoid the pitfalls you can’t possibly know about because you’ve simply not experienced them. While your expert is helping spin up the deployment at a much faster pace than you could have yourself, and helping you to avoid the pitfalls they’ve already experienced elsewhere, you’ve got to be peddling as fast as you can to increase your own knowledge. Good implementers will be committed to knowledge transfer and will not expect to be there forever.
Becoming an internal expert does take effort but if you combine your own D-I-Y studies with external training and on the job training while working with an experienced implementer, the payoff is significant.