Another point of confusion to those who are new to kanban is that what are traditionally known as risks in a project delivery sense are different to what we describe as risks to overall risks in a kanban system. The two are actually quite different – when you consider a project, this is often a single item on a portfolio or program level board. That is it is a single work item and any “project risks” just relate to that work item. When we talk about risks in a kanban system, these risks will flow across work items and impact the system and its customers more holistically.
A number of people turning to kanban today have at some point in their past or present been responsible for the delivery of projects. That is, we’re seeing more and more project / program management folks start to take up Kanban and run into this misunderstanding. This is a key difference in the kanban lens to the project lens – one looks at a system overall, whereas one focuses on an item within the system. We know from basic lean thinking and kanban that if you optimise for a sub-part of the system, you’ll sub-optimise the system overall. Thus, many project managers fall into the trap of trying to minimise the risk to their project (or “work item” in the kanban system). Oftentimes, even though unintentional, by doing so a project manager will create a sub-optimal overall system – thus increasing risk to other deliveries.
This kind of behaviour no doubt comes from how we measure responsibility – often project managers are responsible for the delivery of a single project to be on time and budget. I have seen this overtly in some cases – where project managers will blatantly say that they’ll take a particular course of action that oftentimes put other delivery at considerable risk. They have no responsibility for the system as a whole. Oftentimes, no one does. This is particularly problematic because no one is looking after the risks for the overall business and how delivery of work relates to this. The business is facing a number of risks overall.
From a kanban perspective, we consider risk in terms of things such as cost of delay – these things will have a cost impact measured over time to the business. We consider system problems such as blockers and bottlenecks as significant risks – these are going to affect the tail of our lead times which impacts our predictability and ability to deliver reliably.
If you’ve been involved in project risk reviews, you’ll note that the Kanban cadences are undertaken somewhat different when looking at risks. Key among them is the Kanban risk review – this is entirely a data driven conversation, backed up with anecdotes and other qualitative aspects. We look at things such as lead time, blocker / defect data and other items and create improvement actions / changes to address the key issues. For example, if we find that the items in the tail of the lead time were caused because a specialist wasn’t available as they were on leave, we might look to start to upskill others in that speciality. Furthermore, in the Operations review, we look at bottlenecks and blockers to the overall system and look to drive them out with improvements across projects and teams.
In the replenishment meeting, we look at various risks, including but not limited to cost of delay and decide on which items to pull. Risks to the business are considered and balanced when making “pull” decisions. For example, we might look at the due date for items and decide which items have the largest impact on revenue, costs or other aspects of the business. When replenishing, we might look at our overall system and make sure we have the right balance of risks – do we have any intangible items in the flow, are we consider other risks elements such as technical risk, are we focused purely on cost saving and not enough on revenue generation.
Even the humble kanban meeting, we consider risks – for example, we highlight blocked items for action, or look at which items are ageing when considering the flow in the system and what to work on.
This is considerably different to project risks – those things that might impact the delivery of an item in the flow. Things such as vendor readiness and capability, approvals for items, communication of changes, estimation / scheduling errors. These are all things that could potentially impact the value derived from the particular item – but the primary focus is on just the work item, not the overall system. Thus we can often see workarounds rather than systemic fixes through a project risk lens – it doesn’t make sense for a project to pay for a full solution when a quick band-aid will do. In kanban we often consider systemic fixes to problems such as this because we know that multiple items will likely hit the same issue and it makes more sense for the business overall to remove those risks than to just avoid them in the short term.
In deciding which risks to tackle, usually project managers will seek to reduce all risks to their own project. This may increase risks to other projects in the system if a full system focus is not taken. In Kanban systems, sometimes we’ll accept a risk to an item if the solution to the risk will produce an unfavourable result overall – for example, we may need to delay a project because it’s cost of delay is less than another if they are vying for the same people or resources.
Business risks in Kanban systems are inherently different to project risks. Whilst there may be overlap, generally speaking the business risks we consider in Kanban system apply across the system, whereas a project risk will relate to a single project / work item within the system. You’ll get a different view when you look through this different lens. Please consider looking through a broader Kanban lens when you are reviewing risks.