Successful Rollout PlanningIT organizations should follow a careful release-management process for moving projects from development through production.
The ITIL Service Support book provides a great checklist in Annex 9A that highlights areas for consideration. This article will cover some key points in the checklist as well as several additional areas to review:
The CAB is an integral part of change management and is comprised of the stakeholders of a given system. A typical CAB includes representation from at least one aspect of the business, IT operations, IT security, IT development and so on.
The intent is to have changes reviewed by an appropriate cross-section of the organization. For rollouts, this team is integral to assess planning, communicate status and concerns, etc. If the CAB doesnt already exist, it needs to be formed prior to the commencement of the rollout process and review activities. Ideally, the CAB would have been formed during the early phases of the system development lifecycle (SDLC).
Predecessor Requests For Change (RFCs)
All outstanding RFCs that the current system depends upon must be reviewed.
They should be prioritized into at least three levels high-priority RFCs must be implemented and tested prior to the new system being rolled out for the system to perform core functionality, medium-priority RFCs need to be implemented for important functionality to be operation, and low-priority RFCs are ones that the new system can leverage but are not critical to going into production.
The prioritization must happen in advance both for risk management, and so objective decisions can be made if some RFCs are not ready when it is time to do the roll out.
Operational Expense Budgetary Review *
The checklist should include an assessment of the operational expense budgetary impacts. This should have been done far earlier in the SDLC.
The intent is to have a control gate to ensure that budgetary needs for operating the system have been reviewed and approved by operations.
There needs to be formal documentation about what must be demonstrated to the business for the release to be considered a success. Will key inputs and outputs be tested to validate that the release has been implemented and functions as planned?
Whatever the tests are, they should be formalized. The results should be recorded, signed and approved by the relevant stakeholder(s). This evidence is vital as auditors may request it and other documentation relating to the release to show that it was appropriately scrutinized and approved.
Emergency Fix Policy
How will emergency changes be handled during deployment? As with other emergency changes, the fixes should not bypass processes yet follow their own defined process that identifies how change requirements will be identified, reviewed, developed, tested, approved and implemented.
Time is a critical component, but so is risk management. Emergency fixes must balance the need for quick changes with security, availability and integrity concerns.
Should an issue arise during implementation, how will the original state be restored? Planning for a rollback to a previous release must be done in advance as it isnt always straightforward.
The rollback plan should take into account not only the activities, but also the time needed to recover. This will be important to some shops that have concrete change windows that cannot be violated. In their case, they must have a point wherein a go/no-go decision is made that either allows the implementation to proceed or where the implementation activity is halted and the rollback plan is executed to make sure the change window isnt violated.
This is a subset of the predecessor RFC observation made earlier. RFCs should be issued to security for any updates to the security environment that are needed for the new release.
Before the system is implemented, the security posture must be reviewed to make sure it is ready. This is highlighted only because operational security impacts too often are overlooked. Hence, the important of having IT security on the CAB not only to review the systems security but also to review impacts to the overall security environment.
Formalize Your Own Process
Some organizations will adopt the ITIL 9A checklist as-is for their release management rollout process. Others will need to eclectically borrow the points that make sense based on their own needs.
The intent is to have a final review during release management to ensure that the release can be implemented as planned and the risk of rollout failure reduced to an acceptable level.
* Added by the author, meaning it isnt in Annex 9A.