The following checklist is for transitioning a new service from a project team to an operational support team in an enterprise IT environment.
- Monitoring and alerting. Consider key services, components, and related thresholds. Consider capturing syslogs to allow early identification of unusual logs (this requires a log monitoring solution).
- Reporting. Identify what metrics need to be reported to drive and evaluate service value. For example, how often the service is used, or not used. Is this a manual or automated activity, and if so on what frequency?
- Capacity. Have a documented process for expanding capacity.
- Licenses. Have a documented process for renewing and managing licences. When to order, how to order, validating what to order.
- Configuration management. Capture Configuration Items in your relevant CMDB. Solution components, related service accounts, certificates/ secrets (and their expiry dates).
- Design documentation. Where is it stored? Does it capture sufficient detail and is it aligned/ updated to the final configured environment?
- Service description. Who can use the service, what are the benefits, what are the features, who do users contact for information, is there a charge?
- User training. Is there end user training required, and if so, how is this provided?
- Support training. Is support team training required, and if so, how will this be provided? Does the support team have the necessary minimum skillset for training to be effective?
- Service cost. What is the ongoing service cost. Where is the budget.
- Service acceptance. What is the process for formal acceptance of the service into operation, and which of the items in this list are required for service acceptance?
- Non-production environments. Upgrades, patching and new feature releases may need non-production environments. Are these required and/ or available?
- Test plans. Having a record of the testing completed before production release is a great way of giving support teams confidence the service is ready for production use.
- Warranty period. Once a service is live, is there a period of time that the project team will assist with any support issues?
- Support contracts. Are there any support contacts and how do these relate to the support responsibilities and on-going costs. What period of support has been funded by the project team before renewal is required?
- Roadmap. What is the roadmap of the service in terms of upgrades and retirement.
- Access and permissions. How is access and permissions to the service provided? (who can request, who approved, who provisions and how is provisioning completed).
- Support flow. What is the support flow for requests and incidents? Which teams provide 1st, 2nd, 3rd level, etc support? What checks are completed before passing to another team?
- Backup and recovery. Is there a defined process, has it been tested, can the support teams run the process?
- Disaster recovery. Is there a defined process, has it been tested, can the support teams run the process?
- Pro-active maintenance. What proactive duties are required and on what frequency?
- Dependent systems. What the systems dependent are dependent on the service and vice versa.
- Security testing. Is there any security testing required before transition.
- Responsibility matrix. Who has ongoing responsibility for the items on this list, and who is the overall service owner?
If you liked this checklist, please give me a clap. If you have suggested additions please let us know via the comments.
Leave a Reply