In our last article, we examined how changes to existing services and the introduction of new ones are essential to the operation of an IT organization or department, which is why the ISO/IEC 20000:2011 standard devotes significant attention to the Design & Transition of New or Changed Services (Clause 5).
Again, we will continue on with BrightTalk’s webinar on the topic. You may tune in to this webinar, presented by Mart Rovers, by clicking on itSMF SIG: ISO/IEC 20000 SMS Under the Microscope: Design & Transition of New or Changed Services.
In this article, we will see how the DTNCS Process fits into the usual IT work and how it relates to some of the other SMS components.
Obviously, if management is not behind to supporting your project, chances are, nothing will happen. As for the Service Requirements, these will stem from customer, business, standard, statutory or regulatory requirements, or even requirements or needs of the service provider. It is these requirements that will create your need to come up with new services or changes to existing services. When examining these requirements, you will figure out if you need a project to meet them. This is why there’s a very clear interface between the DTNCS Process and the Service Requirements.
Governance of Other Parties
If your project involves third parties, you will need to decide what that third party is going to be responsible for in terms work and managing the incidents. How are you going to govern that third party? Your project should be able to address this and, eventually, implement the solution with the third party.
This includes Resource Requirements, Competencies and Skills. Anyone who’s ever done a project knows that you need resources to do a project. The people, time and money you will need are usually determined during the planning phase, which we will cover in our next article.
Establish and Improve the SMS
At this point, you have decided to go ahead with your project(s). Your Service Management Plan is a critical part of establishing the SMS. Based on Service Requirements, you will determine the need for certain resources to do certain projects. Your Service Management Plan should reflect the fact that you’re going to do these projects in order to meet your Service Requirements. The new or changed services you plan for need to be based on what is in your Service Management Plan. Not surprisingly, that’s an interface that auditors will look for. If you’ve lined up 15 projects this year in IT, or in your organization, then you need to show how they relate to your Service Management Plan. You need to establish that relationship.
You should take advantage of your existing Project Management approach/methodology and best practices. Since that should already be in place, you won’t have to start from scratch. You should also incorporate Requirements Management process/practices/approach. Ideally – though only sometimes – these would already exist and you would have a full-blown Requirements Management Process in place. However, the standard (ie the auditor) will look for you to have a way to verify that the requirements are met. Sometimes, that is done through the Project Management approach. You certainly benefit from incorporating it your DTNCS Process.
Don’t forget to incorporate (Project) Risk Management practices. PMBOK and PRINCE2 both have a risk management component. You should ask “What are the risks, what is the likelihood of those risks and their impact?” Anything along those lines will help you meet the requirements of the DTNCS Process.
Another item to remember is to include Resources Management (4.4). It might be in a different section of the SMS, but it’s important. Your project should be in synch with financial resources, information resources, human resources and technical resources. Think in terms of how many more servers you need to do these projects, or more developers, etc.
Clearly define, implement and manage the interfaces with Control Processes, the Relationship Processes, the Service Delivery Processes and the Resolution processes. This is a good example of the integrated approach. Anytime you do a project, you should have a conversation with the process owners. If this new project or this new service gets the go-ahead, what does it mean for your incidents, your configuration items, your CMDB? What does it mean for your release plan, your capacity needs (servers, bandwidth, etc.)? You should identify all the process owners concerned and have them constantly involved throughout the lifecycle of your project. It’s not unlikely that an existing process or procedure would have to change for this new service or change to a service. The standard/the auditors will look to see if you talk to these process owners when you do these projects and if they are aware of the impact to their process.
This article is part of a series that focuses on specific processes related to the SMS. The next one to be published will delve into the first phase of the Design & Transition of New or Changed Services Process: the planning. If you have any comments or questions related to this post, or any other, please feel free to contact me.