hurdle

The lesson was brought home to me in an unusual setting. I was speaking to a chemical expert who specializes in commercial swimming pool chemicals. He was explaining how the chlorine in the kills the bacteria which carry the bad bacteria. Until you reach the critical mass of chlorine, he explained, zero chlorides have been used and no bacteria destroyed. Once you hit the critical mass, all the targeted bacteria in the pool die and then you have to maintain the minimal critical level of chlorine to keep the pool safe.

What does this have to do with enterprise project management systems deployments you ask? Everything. Take a recent case in point that we’re working on right now. This is a CRM system deployment. The client has (not unusually) completely underestimated the total effort required to deploy the system. They’ve elected to put in a minimal budget with the thinking that their own personnel will be able to carry the project forward at a leisurely pace. The budget had very little room for experienced and expert assistance and was mostly focused on functionality training. Internal technical personnel were also budgeted for the smallest possible amount of time perhaps thinking that the internal personnel would be as efficient as a consultant who had done many of these implementations.

I’m sure you can see where this going. The budget for both external and internal technical expertise was quickly expended and, while the CRM system is installed and has some elements of the functionality working, there are large areas of the product which cannot yet be used because either they aren’t at all functional or they have not been configured with the necessary templates. Underlying architecture is also an issue. In one case the web server required both an upgrade and additional configuration and in another an incomplete installation of Microsoft Exchange had to be tackled. The end result is that the system does not yet have sufficient forward momentum to ensure it’s viability as a corporate system. What will happen here is that either the company will let the system limp along until something better comes along, or the system is abandoned or until it applies a bunch more resources and money to the project (perhaps even more than would have been required originally since they’ll be trying to rescue a project that’s already underway).

Sound familiar? I hope not. But this is exactly the scenario we often see in the enterprise project management space. The amount of effort required to validate the infrastructure, install the software and (most of all) configure the final system is underestimated about 90% of the time. A compounding issue is that the level of expertise and experience required is also almost always underestimated. The result is that systems do get installed but have elements that are not working and too little time to configure the system to deliver the results that were expected when the deployment was authorized.

There’s not a panacea for such deployments. Educating management, if possible, can reduce the heartache. If you are involved in an enterprise project management systems deployment, then determining the minimal working system may be a critical step in your planning. Aside from defining the complete deployment requirement which may be daunting to management, determine also, what effort would be required for a ‘viable’ deployment. One which, even if not all the functionality was deployed, would realize enough business benefit to be worthwhile. If you do, then the system will still be around to expand on later. If not, then you might end up with one more system to be rescued or replaced and all your efforts wasted.