Newton's third law of motion states that for every action, there is an equal and opposite reaction. Modern IT gurus state that for every successful action completion, there is a well thought-out plan. Be it projects or services, a plan is worth half the battle won.
The Service Management Plan (SMP) is a document that contains all the necessary details to run a service. A project management plan is developed on the other end where projects are executed.
IT service management borrows heavily from the Deming's cycle, which is based on four iterative actions — plan, do, check, and act. The gist of the cycle is that you plan first, implement whatever you have planned, check if the action completed takes you where you want to be, and take necessary actions to bridge the shortcomings.
When should a SMP be drafted?
I will compare SMP with a project management plan (PMP — not the certification), which is far more popular, in an attempt to strike a harmonious chord in what I want to convey regarding SMP.
A PMP is drafted and finalized after the chartering process, before the actual project begins. A SMP ideally must be done before a service is implemented, but it can just as well be put into practice during the running period. The reason for this is simple — a service is an ongoing activity, unlike a project, so the saying better late than never applies to the word.
Some organizations leverage on a service implementation plan during the implementation stage and then switch over to a service management plan after a few months. In the core, both these plans are one and the same.
Term for a Service Management Plan
A PMP is in motion until the project closure, but how long should a plan for service run? A service generally runs for an indefinite period, so how can it be planned? Remember in IT, technology obsoletes faster than the imagination can catch it. So, planning for a longer term is not a viable option.
Most organizations plan their services once a year and review the plan every quarter — as a health check and to improve the plan based on what was encountered in the previous period.
Sometime around the fourth quarter, plans kick in for the next year, planning the upgrades that may be necessary and meeting new demands as put forth by the customer.
In one of my previous jobs, I was placed in a challenging environment and set against a difficult customer. To meet the requirements put forth, I planned a monthly SMP during early life support and moved it to quarterly thereafter. The monthly SMP gave us an insight on the ever-changing needs of service delivery from various perspectives and helped us fine-tune it and achieve stability in a short period.
In essence, your SMP must be prepared to satisfy the requirements that stand before you, the environment that houses the service, and the pace at which the technology changes. Finalizing on the optimal period for a SMP is an art that is mastered by experience, so now you know why experienced service management professionals are paid so well!
Typical content of a Service Management Plan
Basically whatever is necessary to run and maintain a service needs to be documented in a SMP. The contents of a SMP will be at the organization's discretion. Here are some of the common items that go into a SMP:1. Scope — The scope of a service draws a boundary where the service can step into and where it cannot. Mature organizations not only have a section for scope but also out of scope. This ensures that there is no "reading between the lines." 2. Brief description — A couple of sentences on the service offered helps in setting the context. Maybe a server team is providing DNS service alone to a particular customer. 3. Support window — Include something on the lines of 24 X 7 or 16 X 5, specifying the times, time zones, and days of the week when support is provided. 4. List of activities — It's very important to list each and every activity that comes in as a part of the service. Leave no ambiguity on this one. 5. Effort and resources — The total effort required to keep the services up and running and the resources in terms of servers, licenses, etc. should be spelled out. You should express the effort required in FTEs (full-time effort, meaning people working full time). Budgets can also be a part of a SMP. 6. Organization chart and escalation matrix — List the team structure and hierarchy. 7. Dependences — Other services that support this service, suppliers, and the architecture should be diagramed to indicate relationships. Example: For a SAP service, there will be dependence on the server team to keep up the infrastructure and the operating system. 8. RACI matrix — Any service will have various roles, such as analysts, coordinators, team leads, managers, supporting team's personnel, and so on. You must map the activities listed to roles, indicating the accountabilities and responsibilities. 9. Processes and templates -- A link to the process documents and templates is preferable to keying the process as a part of this document. 10. SLAs and KPIs — A link should be made to the Service Level Agreement (SLA) and similar agreements like the Operation Level Agreements (OLA). 11. Compliances — List the certifications and standards that the service must adhere to, like ISO 20K, ISO 27K1, PCI DSS among others — and the actions that are planned/undertaken to satisfy the controls. 12. Tools used — Tools that are leveraged to run the service, like the service management suite, CMDB, monitoring tools such as Microsoft Operations Manager (MOM) and ANgate should be included. 13. Governances — Many people hate reports and look at them as major time hoggers. But managers swear by them. You should record reports, meetings, and other governance aspects in the SMP. 14. Communication plan — A service management team generally communicates directly with the customer or through the service level manager. There will be several levels of communications — manager level, with suppliers and others. You should list them all and place templates for each one of them for consistency. 15. Risks — A major exercise in any planning operation is identifying the risks and drawing up mitigation plans if the risk materializes. 16. Pipeline —This document should include, along with tentative dates, upgrades and activities that are planned, such as a memory upgrade depending on the expected new demand from the customer or an ISO 20K surveillance audit that's due next quarter. Even though I'm stating this as the last item in the list, it's very important.
This list is by no means comprehensive and must strictly be treated as a guide to drafting a SMP.
Signatories and sign-offs
The SMP is not an agreement, so no approval or sign-off is necessary from the customer. SMP is a planning document drafted by the service organization and maintained by the service organization to ensure that the contracts and SLAs are in the desired range.
Organizations generally get approval from internal higher management before the ball gets rolling. And, it is a good practice to share certain portions of the SMP with the customer to gain confidence and possibly get new business by showcasing meticulous planning exercises.