ITIL as a requirement

Next Story

The Small ITSM Consultant Dilemma

Supplier Management: How do you know suppliers use ITIL?
You need to write a tender or RFC document and, when you ask him if he knows any particular requirements, your boss says; ‘Make sure they’re using ITIL’.

That’s great, he’s right that ITIL is important, but that simply isn’t a ‘requirement’ in the proper sense. Even if it was, how would you be able to tell that they were?

The only objective test is ISO20k – which has to cover the scope of the service offered (an important qualification, without which it could be useless). There’s a problem even then, though. ISO20k is re-certified every year, how can you be sure that it’s keeping on track during the year? One ISO20k auditor might be more stringent than another – can you be sure that the auditor has checked that the impressively documented processes actually happen in practice, every day, even when he isn’t there?

More practically, and easily demonstrable, that external parties ought to be able to supply access to their service catalogue and that you ought to have access to an up-to-date and complete service design package (SDP) for all services.

If you have an up-to-date and complete SDP, then you have every single thing you need to understand, measure, manage, improve and monitor a service. If an organisation is able to produce one that is adequate without ITIL, that’d be even more impressive, something like meeting a hen with incisors.

You could insist on having documentation covering ITIL processes, or particular metrics – unfortunately, it’s quite easy to produce a document that looks good, but more difficult to demonstrate that it’s what actually happens in practice.

A proper, up-to-date SDP, though, is very difficult to fake. The SDP contains links to all the information about the service, including recent incidents, problems, and changes. So, at any time, you can check to see that it is being actively managed, along with all the processes it documents.

As an example, here are some headings that you’d expect to find in an SDP, with links to the detail:

  • Service Requirements
    • Governance requirements & critical success factors
    • Business requirements & critical success factors
    • Business value Requirements
    • Business constraints
    • Business demand
    • Service knowledge requirements
    • Service applicability
    • Service contacts
    • Operational requirements
    • Stakeholder requirements
  • Service Design
    • Service Functional requirements (Utility)
    • Service Level Requirements (Warranty)
      • Service Security
      • Service Availability
      • Service Capacity
      • Service Continuity
    • Service Constraints
    • Service and operational Management Requirements
    • Service Demand & Capacity
      • Projected patterns of demand
    • Service Design and topology
      • Profiles (user, customer, staff, stakeholder)
    • Service CSFs,KPIs, Metrics design, rationale & measures
    • Service Value Measures
    • Service Cost Measures
  • Organisational Readiness Assessment
    • Service Lifecycle Plan
    • Service Plan/Programme
      • Scope, Objectives, Goals, Targets
      • Deliverables
      • Timescales & Milestones
      • Communication plan
      • Roles, Skills (RACI)
      • Training Plan
      • Critical Success factors (CSFs)
      • Metrics, KPIs
      • Integration
      • Processes
      • Resources
      • Budget
      • Progress
      • Interfaces
    • Service Transition Plan
    • Service Operational Acceptance Plan
    • Communication plans
    • Contracts
    • Agreements
  • Service Acceptance Criteria
    • Stakeholders
      • Governance
      • Customer
      • User
      • Staff
      • Partners
      • Suppliers
      • Shareholders
      • Legal/Regulatory
      • Audit
      • Other stakeholders
    • Transition
    • Operations
    • Environmental
    • Good corporate citizenship
  • Service Transition
    • Changes
      • Technical
      • Service
      • Organisational
    • Releases
      • Development Plans
      • Development Reports
      • Development result
    • Configuration
    • Service Validation & Testing
    • Change Evaluation
    • Transition demand & capacity
    • Service Knowledge Management
  • Service Operations
    • Service satisfaction statistics
    • Governance / Policy statistics
    • Communication statistics
    • Service requests
    • Events
    • Incidents
    • Problems
    • Value / Cost statistics
    • Access statistics
    • Security status
    • Capacity & demand, patterns & statistics
    • Availability statistics
    • Continuity test results
    • Change implementation statistics
    • Notable trends
  • Continual Service Improvement
    • Suggestions
    • Planned Improvements
    • CSFs,KPIs, Metrics results & Trends
    • Improvement status
    • Improvement implementation progress
    • Improvement value / cost statistics

If you do make an SDP a requirement, you can refer to the Appendix of the ITIL Service Design book for a definition. The appendix gives a list of the minimum requirements for an SDP. There is also this paper that goes into considerably more detail about the SDP and the design process it supports.

 

The following two tabs change content below.

Peter Brooks

Peter Brooks is an Author, Consultant and Trainer in Service Governance, based in Cape Town. He has been an independent consultant for the past fifteen years, and, before that, worked for Hewlett-Packard, mainly in the UK, for twenty years. He is currently a director of the itSMF SA and has previously been director of the itSMF International.

Latest posts by Peter Brooks (see all)