1. Proactive risk management

This is a rather simple principle of including contingency in your schedule and delivering the highest risk items early on. However many large enterprises do not seem to like the word contingency in any plan and even if that is approved by all the stakeholders as a formal block of time on the Gantt chart, everyone now knows about it and takes it easy, defeating the purpose. So there are really only two ways to do this. A simpler way was to discreetly work with the executive sponsor and draw up a date before the actual deadline to factor in the contingency and use that as the working date. The executive sponsor, in turn, commits a date including a contingency period to his board, etc.

Sometimes this is not possible, especially in case the commitment is on a press release to end-users or if there is a certain product launch or external event /contractual obligation that constraints our deadline. Such was the case with our example here where we had the date fixed for the launch of a greenfield B2B eCommerce site for a large enterprise, where we were doing a project for the first time, attempting to build this site from scratch in 9 months. There were multiple risks associated with this program, one of them being that we were trying to launch this on the cloud with several integrations into their legacy systems. As per client standard practice, nothing is rolled out into production until all the signoffs are obtained which meant tested code, content, etc. Battle scars from my past warned me that this cannot happen smoothly given all the network connections in production that needed to be made, firewall ports opened, etc. So I had to package the “contingency” differently without using that word. We called it soft launch for the internal users to test it in production a month earlier on April 9th. This approach was approved by the stakeholders once we convinced them that the firewall would be set up so the external world cannot access the site except for users from within the enterprise firewall. On the actual day of the launch, all we had to do is to open up the firewall for external traffic. As feared, there were issues with setting up production routing, load balancers, etc and we missed the soft launch date. We instead soft-launched after a couple of weeks debugging. If we had not planned it this way, our real launch would have slipped by 2 weeks, with a lot of drama and high adrenalin. This soft launch also enabled us to ensure all aspects of the site (content, pricing, products, promotions, etc) were “tested” in production catching many small (and some large)  issues proactively.

Happily enough, on the actual day of the launch, we had a very quick status call just to verify that the site was accessible from the outside and started watching traffic. There was no drama at all. Hopefully you find this strategy useful to have smooth – on-time -launches. Now you might ask that this works for greenfield launches, but what about a major upgrade to an existing site? How do we de-risk that? I have a post coming up on that specific topic – how we helped micro-services migration journeys for several large retail sites. Meanwhile, please like and share this if you find this is useful to others.