Enterprise Project Management and Do it yourself
Author: Chris Vandersluis
© 2007 Chris Vandersluis
|
The Do-It-Yourself movement is strong. It is the age of empowerment and people are being empowered these days to manage their own projects. You can DIY just about anything these days as a quick trip to the local bookstore will attest. Need a new deck? Plans are on the CD enclosed. Need self-help for your emotional upheaval? Emotinal healing is contained herein. Need to lose weight or start a business or do your taxes or fix your medical problems? You can do it yourself.
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 on how 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:
1. 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)
2. They do some of it themselves. You read the book, but you call in the 2nd 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 leg work but in the end the deck looks pretty good.
3. 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 6 and 12 months. What's the difference between 1 and 26-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 and finally; 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; e) 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 70's and 80's the costs 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 of services has, unfortunately, dropped proportionally. We regularly get calls from organizations asking if we can complete an epm system deployment in 3 or 4 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. 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 come by in books. That person inevitably comes with experience of doing 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. That's the kind of experience you can read about but you can't learn. It's the kind of lesson that's phenomenally valuable. 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 to avoide 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. You need to be working hard to become the internal expert with outside training and the internal deployment expertise.
- End -
|
