Going Live: A White-Knuckle Experience
If someone were to write a book called “Great eCommerce Site Launches in History”, the book would be very thin. With few exceptions, the replacement of an existing eComm Platform with a new one is a wild ride filled with crashes, slow-downs, time-outs, and roll-backs. In this post, I will discuss the source of these bad experiences, and how to improve the situation on your next project.
Early in the project, the team is focused on gathering the requirements, creating the customer experience and designing the back end connections to the legacy systems. “Going live” seems safely in the distant future, and gets very little attention up front. As a result, the deployment is handled by a team that is exhausted from the push to finish the coding on time. Errors are made and sites crash. Revenue is lost, managers are embarrassed, programmers are stressed out, etc. There has to be a better way.
A better way would be to think of a new eComm system rollout as two projects, not one. One project goes from strategy to the end of unit testing and the other starts when the programming is done. Two managers, equally skilled, should be assigned, one Programming Manager and one Deployment. At the moment very that the programming manager is totally exhausted, the Deployment Manager takes over with a fresh outlook and fully-charged batteries. While the development team was killing itself to hit the deadlines, the Deployment Manager was managing the installation of the new hardware, preparing the testing environments, getting the test scripts done, planning for the performance testing, etc. Once the unit-tested code gets checked in, the focus moves from software development to testing and rollout.
Another improvement is to actually plan for the inevitable system failure in the first few weeks after you try and go live. Instead of saying a prayer and turning the new system on for 100% of your customers, it would be far better to put a few customers on the new site, and then increasing it steadily over the following 4 to 6 weeks until 100% of the customers are converted over. The alternative is to pretend that you can really find all of the bugs, when you know that you cannot, because no one ever has. By turning on a few users, you can normally defer bugs that show up only under a heavy load for a few weeks. This gives you time to work out the logic errors before the whole world, including you management is watching.
Comments
Thanks Stephen for the post. I agree for having two managers to cater to development and deployment as base deployment activities are independent of development and can start in parallel to development.
Another thought I have is regarding the development process itself. People usually identify the SDLC phase viz. Analysis, Design, Implementation, Test & Deploy for any software project. But for a eCommerce project not only are the phases different but even the activities in it. for e.g there has to be an activity in Design phase where the structure of a catalog /sub-items needs to be decided. This is unique to an eCommerce project, so is say deciding on the Marketing campaigns and the mode - eMail,Site, Viral etc. I feel there is scope to build a Development strategy for eCommerce project and also this as an opportunity for a Design tool vendor like Rational to incorporate it and rationalize it across the industry. Lets say I use Rational to manage my eCommerce project, it should tell that after the Design phase, I have completed all these activities(standard + specific) and I have all the artifacts stored at one place.
Thats my 2 cents here...
Posted by: Sandeep | December 12, 2008 06:57 AM