SMS Policy – How to create it according to ISO 20000

Topics like management and strategy have a special “place” in IT, but pretty often – they don’t belong among anyone’s favorite topics. Sure, management of the IT organization is deeply involved in the above-mentioned topics, but everyone else… well, try to talk to the operating personnel (who make up the vast majority of IT employees) inside IT and you will get the answer.

ISO 20000 requires an SMS (Service Management System) policy to exist, and sets pretty clear expectations of its content, i.e., its purpose. When you read the standard, then the questions start coming: What to do with it, why do we need one, where to use it, who does what, etc. Let’s clarify the SMS policy and the standard’s requirements, and answer all those unpleasant questions.

What’s the purpose of it?

First of all, the SMS policy is your internal document, meaning you will not involve your customers in the creation of the policy. But, your customers are “part” of the policy through the services they use. Namely, the SMS policy should be specific to the services you provide and the customers you support. So, some generic statements or documents will not be good enough, because they don’t provide any value to the management, nor for the employees of the IT organization.

That gets us to the purpose of the SMS policy. The policy should be based on the scope of the SMS (to learn more, read the article: How to define the scope of the SMS in ISO 20000) and aligned with the more detailed elements of the SMS – SMS plan and SMS objectives.

The SMS policy is your top managers’ tool to:

  • Define what they want to achieve with the SMS – usually, they are not familiar with the details of how your SMS works, but they have to know what they want from it.
  • Control – with the policy, top management will be able to define who is doing what and examine the results at regular intervals.

Form and content

ISO 20000 provides inputs for the policy, but doesn’t go into details. So, here are the general requirements for the content of the policy, required by the standard:

  • Circumstances of the organization – this is the requirement that says that the policy should be specific to the business case you have. Meaning, it should be specific to the services you provide (remember – no generic statements, as I explained above) and the customers you serve.
  • Service requirements – top management should commit, e.g., by statement, in the policy to fulfill the service requirements (agreed upon with the customer). To avoid such statement being too general, there must be a mechanism to provide evidence that this has been fulfilled. For example, customer requirements are part of the SLA (Service Level Agreement), as well as measurable targets to confirm fulfillment of those requirements. So, it’s measurable.
  • Communication – the policy must be communicated to all employees. That’s logical – if you don’t tell anyone, no one will know. Even more than that, the SMS policy can also be communicated to other interested parties, like your customers or suppliers. An additional requirement is that the policy needs to be understood by your employees. That means that you have to prove a link between the statement in the policy and the result of your employees’ work (e.g., the policy can state that one of the goals is satisfied customers, and proof for that can be a customer satisfaction survey that has the efficiency of your employees in the background).
  • Improvement – last, but not least, improvement needs to be clearly stated in the policy, for both the SMS as well as the suitability of the policy to the business needs and customer requirements.

That was the content required by the standard. Smaller companies can add more details, like:

  • Scope of the SMS
  • SMS plan
  • Resource management, i.e., definition of roles and responsibilities needed to support the SMS

Top management (and their intentions regarding IT Service Management (ITSM) in your organization), together with services, i.e., customer requirements, are the most important inputs that you need to take into account when writing a policy.

What to do with it

So, you made good preparations and collected all needed inputs, i.e., included all the people who are necessary to provide those inputs. The next steps are pretty straightforward:

  • Write and communicate the policy – put the inputs into a readable and understandable form and make sure it is properly communicated (as explained above – choose the method used to communicate, e.g., publish it on the local intranet, and to whom to communicate, e.g., all employees and your customers).
  • Align and re-align – there will be always changes in the business environment. So, keep your eyes open and align your policy (consequently, the ITSM organization and services).
  • Improve – besides the fact that you need to improve your service, the SMS policy is also subject to improvement, i.e., your work on the policy never stops.

The SMS policy is an excellent way to connect your top management with the rest of the SMS. Although it is a strategic document, if you write in the right way it can be an excellent control mechanism for the achievement of the SMS goals and objectives. Further on, if you use vocabulary understandable by your employees and don’t overextend the content – that’s your chance to align your employees with the strategic goals of the organization. Meaning, to align top management and employees to fight for the same goals – who would want more?

Click here to see a free preview of the  Service Management System (SMS) policy that will show you the structure of such a document.

Advisera Branimir Valentic
Branimir Valentic
Branimir is an expert in IT service management (consultancy, training and tools), IT governance (training and consulting), project management and consultancy in IT and telecommunication. He holds the following certificates: ITIL Expert, ISO 20000, ISMS Lead Auditor and PRINCE2.