ITIL Service Management defines a number of terms, this primer is a quick reference guide. You should find this useful when revising for your ITIL Foundation Exam.
Outcome: The output from executing a process that delivers a SERVICE
Service: A way of delivering value to a customer by enabling an Outcome the customer wants to achieve without incurring the overhead of owning the whole process or risks of delivering it.
IT Service: Delivered by an IT Service Provider. It is a combination of technology, people and processes.
There are 3 types of Service:
- An internal customer facing service: IT Service provided to another part of the same company.
- An external customer facing service: IT Service provided directly to an external customer, for example a music download service.
- A supporting service: A service which is not directly used by the business or an external customer but which is required by the IT Service provider to deliver other services, for example backup and recovery.
These service types can be further sub-defined as:
- Core Services: These are the (top level) services that would be recognised by the customer as the service they are paying for.
- Enabling Services: These are services needed to deliver Core Services. They may be visible to customers but are not sold to them in their own right.
- Enhancing Services: Think of these as “Core Services Plus”. They are not essential to delivering the Core Service but are extras used to differentiate the service from its competitors
Service Package: A bundle of two or more services (could be core, enabling or enhancing) designed to meet a specific type of customer requirement or to underpin a specific business outcome.
Service Value: Customers cannot benefit from something that is fit for purpose but not fit for use and vice versa. What’s the point of having a fantastic helpline if its always engaged when you phone it. Service Value therefore breaks down into Utility and Warrenty.
- Utility – What the service gives the customer – it’s fitness for purpose. Think of this as the functionality provided by a product or service to meet a particular need. In my example a helpline that will be able to answer any technical question.
- Warranty – How it is delivered – it’s fitness for use, eg sufficient capacity, availability, security etc. This is the assurance that the product or service will meet its agreed requirements. This may be expressed formally in an SLA. In my example the helpline will be open 24 hours a day and the call will be answered within 30 seconds.
One of the roles of the Project Manager is to identify risks to the project and create a Risk Register. Once the risks have been identified their responsibility is then to work on strategies for managing those risks downwards or out of their project. Below I present 5 key risk management strategies.
- Prevention: by termination of the risk: by doing things differently and thus removing the risk, where it is feasible to do so. Countermeasures are put in place that either stop the threat or problem from occurring or prevent it having any impact on the project or business. For example if you need to relocate a network server you may identify that there is a high risk of disk failure or some other form of hardware failure while the server is in transit. You may decide to prevent this risk by avoiding the move entirely – this could be done by taking a backup on the existing server and restoring it onto a brand new server at the new location. A process that can be easily rehearsed and perfected ahead of the final move.
- Reduction: Treat the risk – take action to control it in some way whether the actions either reduce the likelihood of the risk developing or limit the impact on the project to acceptable levels. To continue the above example, when relocating many servers to a new office you could reduce the risk by moving the servers one at a time.
- Transference: This is a specialist form of risk reduction where the management of a risk is passed to a third party via, for instance, an insurance policy or penalty clause, such that the impact of the risk is no longer an issue for the health of the project. Not a lll risks can be transferred in this way. Continuing the above example again, when moving servers you might decide that contracting the work out to a firm who specialise in this type of work would be a good idea. This would transfer the risk to a specialist but also likely reduce the risk by using people who carry out this type of work all the time and who therefore know the potential problems that may occur and ways of avoiding them.
- Acceptance: Tolerate the risk – perhaps because nothing can be done at a reasonable cost to mitigate it or the likelihood and impact of the risk occurring are at an acceptable level. Bad Weather is a good example of a risk you may decide to accept. For example some outside events can be ruined by bad weather. While it may be possible to take out insurance against this the cost of doing so may be too high to be considered worth while.
- Contingency: These are actions planned and organised to come into force as and when the risk occurs. For example if it rains the concert will be held in the village hall instead of on the green.
If you have alternative ways of managing risks in projects then I’d love to hear from you. In a future blog I’ll look at the best way to present a risk register and communicate how you are managing risks in your project.
