Fixing IT’s Most Costly Mistake – Part 3

This is Part 3 of a 3 part series on using the ITIL Service Lifecycle Stages to work together with development teams and safely release services into the live environment without the usual chaos and outages that take place with these activities. In Part 1, the framework shown below was presented along with key considerations that both IT development and IT operations need to consider. The framework allows both teams to work together in parallel to produce a live service solution together without the typical chaos, confusion, unplanned costs and outages that tend to take place far too many times when solutions are released into the live environment.

In Part 2, we discussed what items to check for at each stage gate before proceeding to the next stage.

Here, in Part 3, we go one level deeper into the above framework to review what support elements need to be in place once a solution has gone live into the production environment.  This is called the Operational Readiness Framework.

The Operational Readiness Framework

The Operational Readiness Framework is provided as a means for ensuring the appropriate solution operational support will be set into place and constructed as the application itself is being developed throughout the entire development lifecycle. This provides the prevention (or early warning in the worst case) of any possible cost overruns, project delays or exposure to service outages. It also shortens the development cycle in that both applications and IT support solutions are developed in tandem releasing together at production deployment time.

The framework provides a broad overview of support requirements that are needed for almost any application solution. It can (and should) be modified for any application unique support requirements that may not already exist in the framework. The solution support and delivery strategy consists of a review of every support area in the framework to determine how it will be handled. This can consist from simply reusing tools and support staff that already exist to buying or outsourcing support from 3^rd parties. (Detailed descriptions for each support area shown can be obtained from the author separately).

The readiness framework is simply an inventory of ITIL process areas taken from the ITIL framework. Every area in the framework (e.g. incident, problem, change) needs to be considered no matter what application solution is being constructed. The consideration should be holistic in that it should include supporting processes, technologies, support responsibilities and 3^rd party vendors and suppliers.

As a first step, the considerations (and hence the strategy) for each area needs to be developed. For every ITIL process, what will be built, used or modified to support the new solution going live? Examples of options for each one can be that as shown below:

As an example, the Strategy stage will identify a management strategy that builds skills in house for support of servers, application, network and storage; outsources monitoring and incident management to a 3^rd party, establish an in-house program for training end users and target in-house process improvements to handle solution changes, implement a load balancing solution for availability and reuse existing capacity services and capabilities. The design and transition stages will then execute on this strategy putting all the planned elements into place in tandem with the application development effort.

The table below highlights operational readiness activities by ITIL process. For an application solution going live, this means walking down this table to identify how each element will be put into place. As an example, for Service Operation/Incident Management/Handling of incidents, will you use an existing solution? Replace what you have? Modify what you have? Outsource incident handling to a 3^rd party? These kinds of questions need to be answered for each process in the framework.

Concluding Thoughts

Billions of dollars get wasted every year for IT solutions that cannot be deployed and operated at acceptable cost and risk. Typically, 6 out of 10 new application systems never get deployed into production due to failure to consider or implement operational requirements. Many organizations concentrate on application development efforts leaving the operational aspects of the solution to be addressed later resulting in massive project delays, cost overruns, production outages and unplanned operating costs. At the same time, operations staffs need to understand how to integrate themselves into the development process asking the right questions and integrating support solutions at the right time such that operational support is built into new applications in parallel with the entire development cycle.

Use the approach presented in Parts 1, 2 and 3 of this series, you can go a long way towards mitigating these risks. Capabilities are created that allow IT organizations and the business to protect investments made in their application solutions by being able to operate them on a day-to-day basis in a manner that meets business needs.