ITProjectManagement.org

The following checklist is for transitioning a new service from a project team to an operational support team in an enterprise IT environment.

1. 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).
2. 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?
3. Capacity. Have a documented process for expanding capacity.
4. Licenses. Have a documented process for renewing and managing licences. When to order, how to order, validating what to order.
5. Configuration management. Capture Configuration Items in your relevant CMDB. Solution components, related service accounts, certificates/ secrets (and their expiry dates).
6. Design documentation. Where is it stored? Does it capture sufficient detail and is it aligned/ updated to the final configured environment?
7. 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?
8. User training. Is there end user training required, and if so, how is this provided?
9. 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?
10. Service cost. What is the ongoing service cost. Where is the budget.
11. 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?
12. Non-production environments. Upgrades, patching and new feature releases may need non-production environments. Are these required and/ or available?
13. 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.
14. Warranty period. Once a service is live, is there a period of time that the project team will assist with any support issues?
15. 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?
16. Roadmap. What is the roadmap of the service in terms of upgrades and retirement.
17. Access and permissions. How is access and permissions to the service provided? (who can request, who approved, who provisions and how is provisioning completed).
18. 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?
19. Backup and recovery. Is there a defined process, has it been tested, can the support teams run the process?
20. Disaster recovery. Is there a defined process, has it been tested, can the support teams run the process?
21. Pro-active maintenance. What proactive duties are required and on what frequency?
22. Dependent systems. What the systems dependent are dependent on the service and vice versa.
23. Security testing. Is there any security testing required before transition.
24. 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.