The Rollout

Rolling out the project (or "going production," as it's often called) is the culmination of the project and can be hectic.

Many companies like to use a gradual approach for rollouts. Stretching out the rollouts, it is felt, gives the team an opportunity to handle any problems on a small scale rather than running the risk of a major fiasco. The trouble is that it's often difficult to schedule meaningful gradual rollouts. For instance, if the project targets support centers around the world and the centers are providing Follow-The-Sun support, it's awfully difficult to roll out one center at a time. I've done it, and having to go back and forth between systems was confusing and burdensome. More importantly, the data never seemed to sync perfectly with each rollout wave.

Another rollout strategy is to run with both the old and the new systems in parallel for a while, until the business users are convinced that the new system is reliable and perhaps even better than the old one. I find using parallel systems to be an unbearable overhead, but your situation may warrant it.

Which brings us to rollout rule #1: plan for the rollout early so that you can make informed decisions about data synchronization and whether to maintain concurrent systems for a while. This is not a decision to be made only by the technical team for technical reasons; the business owners must be fully briefed about the feasibility and dangers of the various approaches so they can support the decision, whatever it is.

The second aspect of rollouts is that, even with great attention to training and even with a very well tested system, some things are bound to go wrong at deployment time. If nothing else, the staffers may get confused about some aspects of the system. On the disaster end of the scale, the system may just collapse. So rollout rule #2 is to plan for appropriate support at deployment time. This means, for the most part, that the entire project team should be on deck and that an emergency support process be in place. Don't dismiss the integrator the minute the system goes live! Yes, it will cost you money to keep the team engaged and yes, you may end up with a team that has little to do; that's called insurance and you will be very glad to have spent the money for nothing if that's indeed the outcome.

When possible, super-users can deliver roving support to staffers who need it while technical staffers are ready to help should there be the mere hint of a technical problem. It's a good discipline to log all the problems as they come in so you can track them to completion and also analyze (later!) where training could have been stronger. Almost all rollouts trigger the need for some immediate changes. Users are at their most vulnerable ”and cynical ”during the first few days of the rollout, so try to address their concerns quickly before they blame the system for all their problems. This means that the project team should remain engaged until the problems simmer down.

Then there is the issue of contingency planning: what if things go really badly ? Is there some kind of fallback mechanism, such as going back to the old system? Rolling back strikes fear in the heart of technical teams because it's almost impossible to do, mostly because the data starts changing the minute you turn the switch. Sure, you can go back to the old system, but you will almost certainly lose some data in doing that. If you simply must have the security of a rollback option, build it into the plan and include criteria for when you may choose to exercise that option, and who is responsible to make the decision. Good luck!

That was rollout rule #3: decide in advance how you will handle rollback decisions. Rollout rule #4 is to keep everyone informed, both the project team and the user community, on what's happening during the rollout. Plan for how the communication will be handled long before the rollout, since rollouts are often chaotic and are not a good time to improvise. It's great to have a communication plan based on the tool itself, but prepare for the reality that the tool may fail; a good old phone tree may be a great tool to have as a backup.

A few more thoughts about rollouts. It's not unheard of that the initial day of the rollout is satisfactory but that problems creep up over time, either because usage was light initially or because problems only show up as more data is entered. Don't declare victory for at least a week after you experience a smooth day, and only if you can verify that the system is actually being used (the managers should be enlisted to check on that).

Unless you have chosen a strategy of parallel systems, turn off the old system as you roll out the new one. Otherwise, users may prefer to continue using the old, familiar system.