Skip to main content

Fixing IT's Most Costly Mistake – Part 3

Author by Randy Steinberg

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 3rd 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 3rd 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:




The process area is not needed to support the solution being developed


Existing support tools, people or suppliers can be reused to support the solution with no more than minor modifications needed


Existing support tools, people or suppliers exist but changes will be needed to adequately support the solution (e.g. new technology upgrades, changes to support contracts, etc.)


Support tools, people, or suppliers do not exist and the desired strategy is to build a support solution internally


Support tools, people, or suppliers do not exist and the desired strategy is to buy these from external sources and manage them internally


Support tools, people, or suppliers do not exist and the desired strategy is to outsource these areas to 3rd parties


Support tools and solutions will leverage Cloud, or Software as a Service Technologies



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 3rd 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 3rd party? These kinds of questions need to be answered for each process in the framework.

Support Area

Operational Support Area

Key Production Consideration(s)

Service Operation

Incident Management

Handling of incidents

Problem Management

Handling of problems

Event Management

Solution monitoring

Access Management

User IDs, Passwords

Request Fulfillment

Handling of solution requests

Service Transition

Transition Planning and Support

Solution deployment activities

Change Management

Handling of solution changes

Service Asset and Configuration Management

Handling of service assets/relationships

Release and Deployment Management

Handling of solution releases

Service Validation and Testing

Testing of solution

Change Evaluation

Evaluating solution success

Knowledge Management

Handling of support/user documentation

Service Design

Design Coordination

Coordinating solution design efforts

Service Catalog Management

Updating service catalog with solution

Service Level Management

Solution service targets and agreements

Availability Management

Managing solution availability and risk

Capacity Management

Managing capacity and performance

IT Service Continuity Management

Recovering from a major disaster

Information Security Management

Securing solution from security threats

Supplier Management

Managing and coordinating suppliers

Service Strategy

Financial Management (e.g. Chargeback)

Service billing and chargeback

Demand Management

Managing impact of business volumes

Business Relationship Management

Service communications with business

Service Portfolio Management

Updating service portfolio

Strategy Management

Ongoing solution support strategy

Operational and Support Staffing

Support staffing and resources

Continual Service Improvement

Service Improvement Process

Identifying/improving solution delivery

Service Reporting

Solution service metrics and reporting

Service Review

Ongoing review of solution quality

Service Desk

Call Management

Updates to call scripts, support models

Training For Call Agents

Call agent training and skills readiness

Service Notification and Contact Lists

Key contacts for incidents/issues

Operations Control

Lease and License Management

Enforcement of license policies

Backup/Restore Management

Backing up solution data/applications

Job Event and Schedule Management

Handling job schedules/batch needs

Timing Services (e.g. Clock Management)

Coordinating timing across zones

Service Startup/Shutdown Management

Coordinating production shutdowns

File Transfer and Control

Delivery of data to vendors/partners

Media Management (e.g. Disks, CDs, Tapes)

Handling of media artifacts

Command Center Management

Command consoles/operator views

Middleware Support and Operations

Transaction queue handling

Print Operations

Print queues, bundling/collating

Management of Spare Parts

Spare parts inventories and dispatch

Equipment Maintenance

HW/SW/NW maintenance activities

Desktop Support Management

Supporting PCs, laptops

Hands On (Repair, Moves, Adds, Changes)

Dispatching hands-on repair as needed

Management of Log Files/Application Queues

Monitoring and processing logs

Archive Management of Storage and Artifacts

Dispatching media offsite

Run Book Documentation

Written instructions to operators

Facilities Management

Site Preparation (Building, Closets, Facilities)

Build out of physical processing sites

Environment Management

Managing power, floor space, etc.

Physical Site Security

Access badges, security cameras

Technical Management

Training For IT Support Staff

Putting support skills into place

Server Management

Managing servers/mainframes

Network Management

Managing network support/bandwidth

Storage Management

Managing storage capacity/performance

Database Management

Managing database platforms

Telephony Management

Managing telephones/VOIP networks

Website Management

Managing websites, website content

Specialized Device Support

Specialized device support skills

Service Management Software

Support for service management tools

Applications Management

Training For Users

Ensuring users can use the solution

Application Maintenance

Supporting/maintaining applications


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.


Randy Steinberg

ITSM Process Architect