Managing project risks with Kanban13 Sep 2022

How a company approaches risk management can often be what makes or breaks it. While Kanban does not prescribe many rules in general, its support for a steady flow style of work allows risk management to be incorporated into it without problems.

Performance history

The most forthright advantage that using Kanban for your process management brings, in terms of dealing with risks, is that it gathers your past performance data. It's invaluable for the process of identification of the root causes of repeatable problems. It can also help you estimate what percentage of a specific work is likely to expect a delay and what size. Such insight will aid your delivery time estimations for clients.

The added WIP limitations

Applying Kanban's WIP limits to processed work allows for risks to be minimized by avoidance: there is less that can go wrong at any time since you're limiting how many work items are started all at once.

Differentiating tasks by risk level

With each work item having a type assigned, not only do you gain the ability to limit how many things are worked on simultaneously, you can also decide how many out of each type can be worked on at once. It furthermore reduces the danger of investing time into risk-posing jobs. Additionally, we can devise a class of service for each of the task types. Keeping a specific protocol of action for the various types of work (so, for work items with varied levels of built-in risk) minimizes the risks further still.

For example, in software development, there usually is a set action protocol for a bug critical to the software's existance and performance - it will have the highest urgency. The provided fix will need to be tripple-checked for potential impact on all other software elements, and its deployment will have the highest prority. Meanwhile, the procedure for working on a new, non-crucial feature will be much more relaxed: do the best you can to achieve the goal, test how well it works and integrates with the other elements, and we'll deploy it when the time is right. It's also common for tasks on the opposite spectrum of importance to be assigned to developers with different experience and skill levels.

Risk sizing

The strength of using card colors for low, high and critical risk types is its simplicity and high readability. But if what you're after is a more precise risk estimation, you can go ahead and give it numerical values.

Typically, the values assigned to the risk size on specific actions come down to weighing the impact of the risk coming to life with the likelihood of it happening (risk = impact * likelihood). You can use the outcome of the above multiplication as your total risk value, or you can keep the two factors separate and assign tasks to workers based on their competence and infallibility appropriate to the read risk points.

Summing up, there would be several ways to visualize and tackle risks on your Kanban board:

• card types/colors
  (e.g., red tasks -> existential risk, orange tasks -> high risk, yellow -> minor bug reported by clients, with all other types of work given various shades of gray type colors);
• risk values
  a number based on your risk calculation, board columns sorted either by that number - from highest down, or by the order in which assigned tasks need to be done in;
• an "Expedited" swimlane
  a presence of a task in the expedited row means that all other work must stop until the high-risk tasks are done. It's possibly the most simple, visual, and effective solution;
• or, a combination of any of the above.

A final, uncomplicated way to minimize risks - strongly connected to kanban daily practices - is briefly discussing the more risky work items (e.g., the orange and red ones) before tackling them technically. By relying on the collective power of all team members, you're more likely to foresee potential hiccups and issues than if you leave the matter in the hands of one specialist.