In a previous article, I described the transition phase and how I broke preparation for transition into two separate groupings of steps. That article went on to discuss the steps leading up to deployment. This article will discuss the second set of steps, those to be done much closer to the time of deployment. These five steps are directly related to the activity of transition.
Design a rollback process. – Following a significant round of testing, nobody likes to think that something could occur in the deployment of a change that would require backing the change out and restoring the former system, but it can happen. It is best to prepare for such an event in advance to avoid having to scramble amid the pressure of dissatisfied users. Take some time up front to define the approach towards reverting the system to its original state. Evaluate several scenarios, including immediate rollback (obvious issues identified at system startup), rollback after a short-term interval (hours to days following some system usage), and after a long-term interval (users have been in the system, data has had significant updates, and perhaps exchanged with other systems).
When performance problems arose with one deployment in which I was involved, our rollback process was seriously being considered. Although the problem was resolved before rolling back, it was helpful to have a fully prepared plan. During times of high stress such as determining the fate of a transition, without advance planning it is likely something important will be overlooked.
Conduct a tabletop PROD deployment exercise. – During this event, all of the participants in the deployment will be either present or on a conference call. The elements of the actual deployment will be evaluated, and the sequence and duration of each step will be validated. Team members should step through the process, explaining what they will be doing and what items they will need at the time of the step to ensure all participants are aware. This step may identify a dependency that was not accounted for, particularly in cases where the operations team is separate from the development team.
One of the biggest advantages that I have seen to this activity is that task ownership becomes apparent. Team members looking at each other, each assuming somebody else was going to speak up means something would have likely been missed during the real event.
Include several go / no-go decision points. – The transition plan should have built into it several go or no-go decision points. These points allow scheduled time for reflection during the deployment to ensure all is proceeding as expected. At each go or no-go point all stakeholders should feel empowered to suspend the deployment. The project sponsor should be willing to accept that the least senior member of the deployment team has as much voice in this as the most senior. Items to be considered at this time include input from the tabletop deployment exercise, the current confidence level of the teams and management, and any unforeseen scheduling interference.
I also feel that these decision points act to lower stress levels. They operate as life rafts, allowing stakeholders to see that there is a way to suspend the final deployment if there are doubts.
Conduct a dress rehearsal deployment. – In this event, all of the elements of the actual deployment should be exercised in some form of staging environment. The timing and duration of each step should be recorded. In contrast to the tabletop exercise, code will get deployed, data will be converted, and deployment verification steps will be done. One outcome from this step is to contact all participating agencies to advise them of any time variance from the tabletop exercise.
Most organizations I support have separate and well-defined staging environments. This serves multiple purposes. Beyond the dress rehearsal, this environment is also a good place to do User Acceptance Testing (UAT) along with Performance Testing.
Advise any consumers of information about go-live. – At this point the partner organizations that either contribute to or use the system’s information are to be made aware of the decision to proceed or to not proceed. Communicating the decision is not only a courtesy; it will likely have an impact on participants who have had to account for your change being implemented.
Following the steps outlined in this and the previous article is no guarantee of transition success. As with most plans, it is possible that reality is different from what is anticipated. But introducing planning at this important phase will ease tensions, clarify expectations, and assign ownership—all things that won’t happen purely by luck.