1. Managing work as tickets

It is important to manage the flow of work (Lean, DevOps and other modern approaches emphasise this)

Queue: when work exceeds capacity within a defined timeframe (backlog)

Manage queues with prioritization:

• Use a ticketing system (paper, electronic tickets, digital interfaces)
• Ticket (record of work): tickets don’t cause queues, queues are caused by an organization’s processes, capacity, and management

Every system needs slack to deal with variation in work arrival time

Can’t always add people to deal with occasional peak loads

Methods for minimizing queues:

• Reduce variation in demand with pricing mechanisms
• Reduce variation in demand with policy
• Increase ability to accept demand
• Deflect demand from the value stream

Queues lead to delays which can impact user experience:

• Mitigate this with reliable status updates
• Keep users engaged in the situation
• Request updates from users to create a sense of activity and involvement
• Set expectations of when users will be updated and then meet these

2. Prioritizing work

All work needs to be prioritized

Priority applies beyond incidents: consider requests, defects, development requests, projects, improvement opportunities…

How granular should work be prioritized ?

• Prioritizing work entering the value stream increases the need to manage user/customer expectations
• Prioritizing work at each value stream step can create or move the constraint or bottleneck, may result in idle resources downstream from the step, may create a backlog upstream from the step

2.1 How to prioritize work ?

• Based on
  • Availability or quality
  • Time
  • Financial factors
  • Source or type of demand
• Triage

2.2 Swarming

Alternative to tiered support groups and escalation

Issues with tiered support include:

• Multiple queues, creating accumulated work‐in‐progress
• Multiple queues may increase the time it takes to get to the right person
• Work may bounce with multiple reassignments:
  • The team escalating the work, by definition does not have the right skills
  • So essential information may not have been collected, and issues may be escalated to the wrong team
• Some teams and groups can be overwhelmed: key specialists can become a bottleneck in the value stream

Single collaborative team, rather than tiered escalation

Dispatch swarm – meets frequently to review incoming work:

• Cherry pick quick solutions
• Validate correct information has been collected

Backlog swarm: convened flexibly or periodically to review backlog

Drop-in swarm: experts are continually available to front line staff

Challenges:

• Perceived increase in per-record cost, because higher skilled staff may be involved earlier
• Difficult to evaluate individual contributions, because work is more collaborative, can affect monitoring and reporting
• Dominant individuals can overwhelm others in the conversation
• Finding the right people to swarm can be difficult
• Requires executive support, loosening of rules, move away from rigid process to culture of self‐reliance in teams

2.2 Shift-left

Move closer to the source

Improves the quality and speed of the work

Reduces the need for and cost of rework

Benefits:

• Faster resolution times (increased productivity and customer satisfaction)
• Reduced number of interruptions (increase in completed projects)
• Reduced incident cost
• Increased in the number and variety of tasks for staff (improved employee satisfaction and retention)

3. Commercial and sourcing considerations

Partner vs. supplier vs. vendor

Main decision build vs. buy:

• Bias based on familiarity with product; shiny object syndrome; aggressive salesperson; pressure to change/reduce costs…
• Why build ? Personalization, requires in-house knowledge, components aren’t mass market, compliance is a high-priority
• Why buy ? Scarce internal resources, lack of skills/competencies, low demand, component not core to strategy, creation is predictable/repetitive

Be aware of commodification

4. Defining requirements for service components

Ensure stakeholder input: requirements should exceed functional requirements

Consider:

• Maintainability and supportability
• Geographic location of vendor resources
• Cultural alignment between the organization and the vendor
• Cost of service consumption
• Architectural alignment (business, technical, and information)
• Vendor brand and public image
• Interchangeability of vendors

Go back to ITIL 4 Managing Professional Certification Course: Create, Deliver and Support (CDS) to finish this chapter or to the main page ITIL 4 Managing Professional Certification Course.