This is often a point of confusion for folks who are new to Kanban and something that I try and clarify for many people during my Kanban System Design course. I find this to be the case when particularly dealing with things such as regulatory requirements. If you don’t make this distinction your Kanban system is going to run into problems as you find the priority of certain items unnecessarily elevated – creating more stress on the teams and risking opportunity costs.
A due date is simply when something is intended to be done. Oftentimes, this may be particularly arbitrary – based on the wishes of a particular stakeholder in the organisation. Other times, there may be a particular cost of delay associated with it. Regulatory requirements often have a due date – when the regulation requires compliance. Additionally, just because something has a due date does not necessarily mean that it absolutely must be done – it should still be treated as an option. Understanding whether to take up that option or discard it will be based on the impact of it. The question “what happens if we don’t do this?” will often help inform whether you need to take up the option.
The due date should influence the starting or replenishment time of the option. For example, if we know we can get through 90% of our standard items within 8 weeks of starting them and we have an option with a due date in 12 months, we don’t actually need to start it for 10 months. It can traverse the system as a standard ticket and not disrupt the flow of other standard items. If we had started that option straight away, it means we’re using our valuable capacity that could have been devoted to something else. Image if that other option was a revenue enhancement that would earn the company $100K per month – we would have missed at least $200K in revenue whilst we were dealing with the option with a due date!
A fixed date class of service is something different. There is a set of policies associated with these that impact the system. Usually these items have a significant risk / impact to the company and thus policies reflect this. For example, teams / individuals may need to drop what they’re working on and switch to the fixed date item. This means the other items in the flow have their lead times increase (ie delays). There’s often a different SLA for these items – to continue the above example, we may have a 3 week delivery expectation for a Fixed Date class of service as opposed to 8 weeks for standard items. This is where the task switching policies come into play as teams look to meet this different expectation. If you’ve committed to an item as a fixed date class of service and it doesn’t have the high impact necessary, you will sub-optimise your overall Kanban system and unnecessarily impact customers of your standard requests.
Thus, when setting up a fixed date class of service, it’s important to make sure you triage items properly and assign them the correct class. You should have policies that stipulate what kinds of impacts will trigger the fixed date class of service – not just the fact that it has a due date. Also, making sure your policies are clear about what to do once it’s in the system are important so that the team knows how to deal with them.
In most cases, you won’t necessarily need to invoke the Fixed Date class of service for a request. Many of these items may well just be standard items and the due date informs when you might want to start them. Consider the impact and make sure this properly informs you as to when you need to start an item.