Identify and define classes of service
This is a series of posts from the main topic STATIK (Systems Thinking Approach to Introduce Kanban) wich it’s an exploratory and collaborative approach to implement Kanban. It helps to understand the current demand and dynamics, to design and implement a Kanban work model that allows increasing the efficiency and quality of the service through the culture and techniques of continuous improvement.
Statik Steps
As an iterative approach, STATIK suggests you go through the following steps.
For each identified service:
- Understand what makes the business fit for purpose
- Understand sources of dissatisfaction
- Analyze the source and nature of demand
- Analyze current delivery capability
- Model the service delivery workflow
- Identify and define classes of service
- Design the Kanban system
- Socialize design & negotiate implementation
Identify and define classes of service
Classes of Service (CoS) have two main purposes: to classify different work items according to their priority and to clearly define how the items in each CoS should be treated.
Classes of Service are used to mitigate external risks associated with a work item. The more urgent, critical, or valuable an item, the higher its class of service is likely to be.
Some examples of CoS are Work Item Type, Cost of Delay, Customer, Project, OKRs.
The selection of the Class of Service should depend on what is more important (in terms of business strategy) for the service or for the organization. CoD is the most I use or recommend within my Kanban implementations when the company has no clear strategical drivers in place. In the end, many business organizations don’t want to lose their money, and this Classes of Service allow us to manage risk related to the cost of delay in their service delivery.
COST OF DELAY PROFILES
Cost of Delay (CoD) is the perceived economic value of a work item through time. It helps teams understand how the value of an item they are working on can diminish over time.
The most common CoD profiles or archetypes are generally as follows:
- Expedite — we are losing a lot of money right now
- Standard — do it as soon as possible
- Fixed date — campaigns, regulations, agreements with customers, …
- Intangible — it will eventually become an expedite if you don’t do it
Teams assess the impact of a delay in the delivery of a feature, project, or solution to an issue. Delaying the release of a version of your software that is aimed at giving you a competitive advantage will definitely have a high cost of delay. In the same way, not being able to immediately release a solution to a critical production issue entails a high cost of delay, as you stand to have dissatisfied customers or even lose them because of it.
IDENTIFYING CLASSES OF SERVICE
Bring examples of expedite, fixed date, standard and intangible demands in their context, and for each example, say which characteristic classifies the demand in its class of service. Then agree with the team about their policies of working.
Next STATIK’s step is Design the Kanban system. Or review the previous step, Model the service delivery workflow.
