Follow us

ITSM Basics: What Is Service Transition? (Part 2)

By | December 18, 2018 in ITIL


Welcome back! I hope you read the first part of this blog that looked at what ITIL’s service transition is – across transition planning and support, service asset and configuration management, change management, and change evaluation – and offered up helpful tips. Plus, that you’re here because you found it valuable.

For this second part, I’ll focus on release and deployment management, service validation and testing, and knowledge management. Again, offering helpful tips along the way.

So, here we go with the final three of the seven parts of ITIL service transition…

5. Release and Deployment Management

The goal of release management is to take an overall view of a change to a service and to ensure that all aspects of that release, including technical and business requirements, are considered together before deploying it into the live environment.

Release management plays an important role in bridging the gap between project management and IT operations – delivering the outputs of each “project” to the business in terms of tangible services.

In doing this, release management provides a structured approach for bringing changes together, testing to make sure that they work correctly, and then safely introducing them into the live environments that business operations rely upon.

Top Tip:  Use A Release Management Policy to Drive the Right Behaviors

One of the most important documents you can have at your disposal as a release manager is the corporate release management policy. This is the document that sets out the key terms of release management and the rules for deploying releases into the production environment.

If you need to create a release management policy, start by looking at other policy documents in your organization so that your new policy has a consistent look and feel to other documentation used within your enterprise. This will make it easy to understand and follow (as well as making it look official).

This policy should include elements such as:

  • Schedule – how often will releases be allowed. This will depend on the cadence of your organization, and there’s “no one size fits all.” Some organizations deploy releases multiple times a day and, at the other end of the scale, there are other businesses that might release far less infrequently. There’s no right or wrong answer, only what meets the need of your business stakeholders (in terms of balancing benefits, costs, and risks).
  • Quality criteria – ensuring that the release is fit for purpose. This policy section will include quality gates and the criteria needed to exit each stage of testing ahead of making the new, or updated, service available to the business.
  • Roll-out planning – how will releases be deployed in your environment? There are multiple options, from big bang to phased, to pilot releases to parallel environments, to continual release models. Know your business and its appetite for risk before proceeding here.

6. Service Validation and Testing

Service validation and testing is the process that ensures that: a service is fit for purpose, it matches the design specification, and will meet the needs of the business.

In other words, Service validation and testing will provide confidence that a release will create a new or changed service that delivers the expected benefits to the business within the agreed cost and risk.

Service validation and testing is a key process within service transition because successful testing increases business, customer, user, and stakeholder confidence plus, of course, the quality of outcomes.

Top Tip: Use Service Validation to Add Structure Around Testing

When performing service testing, here are some points to consider:

  • Validation of utility – ensuring that the service is fit for purpose and meets the operational, functional, and management requirements of the service as per the test criteria agreed to by business, customers, and stakeholders.
  • Verification of warranty – ensuring that the service meets the availability, performance, and redundancy requirements set out at the design stage.
  • Use agreed test criteria – such that testing includes entry and exit criteria throughout each stage of the process, ensuring that all criteria have been double checked and validated.
  • Use governance and policy testing – ensuring that any, and all, regulatory requirements have been met.
  • Apply test models – to test business processes to ensure that the end-to-end service works as expected by the end-user community.
  • Use test types – these are the tools, techniques, and methods used in each test model so that testing is carried out consistently.

7. Knowledge Management

Knowledge management is the process/capability responsible for sharing people’s perspectives, ideas, experience, and information, and for ensuring that these are available (to others) in the right place and at the right time.

Done well, it enables informed decisions, and improves efficiency by reducing the need to rediscover knowledge. Knowledge management is there ultimately to support transition (to make sure that change activity goes through effectively, efficiently, and safely) and other ITIL service lifecycle phases such as service operation – with the right people having access to the right information before, during, and after both planned and unplanned work.

Top Tip: Don’t Overcomplicate Things

When creating a knowledge management, or knowledge sharing, capability look for quick wins – the things that can get results quickly and deliver real value.

Some examples, starting with common knowledge-sharing issues, include:

  • Including representatives from the IT service desk in the user training for major releases. All too often the service desk is the last to know about new products and services. And, even worse is when no one tells the service desk that something new has gone live and they’re forced to handle incidents and service requests with no knowledge or training to fall back on. By including the service desk in end user training the involved analysts will get a holistic view of the new, or changed, service and can then document the highlights for the rest of the team to use when dealing with related tickets.
  • Documenting the most frequently-logged tickets for your most business-critical system. You might not be able to fix everything at the first point of contact but having the most common issues documented will improve first time fix rates as well as freeing up second- and third-line support for the more challenging issues.
  • Capturing information about legacy systems – there’s always at least one application that predates almost everyone in the IT department, which then depends on the skills and expertise of one or two people. Document what was done to resolve each and every incident related to these applications to build up a basic support document for the services.

So, that’s the end of my Service Transition explanations and tip sharing. How do you approach Service Transition in your organization? What advice would you give to others? Please let me know in the comments.

Joe The IT Guy

About Joe The IT Guy

Native New Yorker. Loves everything IT-related (and hugs). Passionate blogger and Twitter addict. Oh...and resident IT Guy at SysAid Technologies (almost forgot the day job!).

Leave a Reply

Your email address will not be published.