”Don’t fix what’s not broken” is a mantra in all technical environments, regardless of industry. Unfortunately, this doesn’t work in the reality in which IT organizations operate as the need and demand for IT services is constantly changing. A transition phase is consequently needed to ensure controlled management of the changes that have to be implemented.
The purpose of Transition is to protect the IT environment in the event of changes, and thereby ensure that when they are deployed there is as little disruption to the business as possible.
Achieving this purpose requires changing activities to take much more into account than simply the specific change. The staff and the systems included in the IT organization must be able to manage the change after it has been implemented. The change itself must function together with the existing IT environment’s architecture. For these reasons, Transition is one of the most complex aspects of an IT organization.
As Transition is a flow through which everything must pass in conjunction with a change in the IT environment. It becomes a narrow sector. This is perhaps the most critical aspect in succeeding with the phase. Secure and bureaucratic management entails long lead times. This will be perceived negatively by those who will be using the phase and lead to the processes being circumvented. Fast and general management of changes risks impairing quality and thereby not fulfilling the purpose of the phase.
In addition to this, complexity is further increased in that most IT environments have applications that are administered by someone outside the IT organization and who traditionally has had direct access to the live IT environment in order to implement changes of their own.
The challenge is thus to create a transition which has sufficient quality and which is simultaneously sufficiently fast and easy to use that all stakeholders realize the value of using the processes in the phase.
Scope
Transition includes responsibility for all changes in the IT environment and that they are implemented taking into account the existing architecture, processes, procedures, documentation, systems and infrastructure.
Transition includes:
- Planning and preparation of changes
- Development and testing of changes
- Eventual pilot’s
- Establishment and handing over to Operation
- Training and transferring of information to Operation
- Evaluation of changes implemented
Overall flow through Transition
In distinction from other phases in this book, Transition is a single flow which is described in three different processes.
The phase is governed by the Change Management process. If necessary, Service Design is used to ensure a holistic overview before major or complex changes are initiated. The construction, quality assurance and finally the deployment of the change are dealt with in the Release Management process.
Transition has no function of its own. The issues which will flow through the phase are usually owned by the Delivery Control and Customer Management functions, which is where the need for changes is usually managed. The phase is usually staffed with resources from the Technical Management and Application Management functions. However, as the phase comprises all changes in the IT environment, different types of administration and development groups outside the IT organization will also be involved in the phase’s processes.
Inputs to the phase:
- Changes in the service portfolio arrives at the Change Management process as registered changes.
- The Customer Management function manages changes that are initiated by the business
- The Delivery Management function manages changes related to the services that are produced
- All functions and processes manage proposals for improvement via the Continual Service Improvement process, which potentially leads to a change in the IT environment
- The operational processes, Operational Maintenance, Request Fulfilment and Incident Management, can result in changes which should be managed via the Change Management process
Outputs from the phase:
- New or updated service documentation
- New or amended component in the IT environment
- New knowledge within the IT organization
