Project Management with Kanban (Part 2) - Sequencing Policies

Posted on August 04, 2014 by David Anderson

In this second in my series of posts exploring project management with Kanban, I'd like to look at how we build a project schedule.

We prefer not to use the term "prioritization" with Kanban because prioritization isn't something done once or periodically leading to a prioritized list, instead prioritization is done dynamically each time an item is pulled through our kanban system. Prioritization isn't an activity in Kanban, it is a consequence of decisions made dynamically based on the risk profile of available work when a pull signal is generated in the kanban system.

Risk Assessment informs Scheduling

Instead we build a project schedule based on sequencing policies. Sequencing policies are based on risk profiles and each work item in the project backlog should have been profiled using a (usually qualitative) risk assessment framework. A very powerful risk dimension is one I call "market risk of change". It is generally described with 5 categories: table stakes; cost reducers; regulartory changes; spoilers (or catch up); and differentiators. This approach is described in my book, Lessons in Agile Management. Other classes are possible within this categorization scheme. On occasion I will embellish the classifications with others such as "misdirector". However, the five described here are the most common. The key point is to pick risk dimensions and classification taxonomies that are relevant to your project. This particular classification is useful for projects where the product of the project is a customer deliverable product or service than competes in market of alternative products or services, and may be in a regularted industry.

Market Risk of Change Classification

If each feature or requirement for the project is classified using this taxonomy then we can build a schedule for the project by setting policies based on the risk classification.

Table stakes have no risk of change during the life of the project. As a result they can be started first. While Regulatory changes are table stakes - you can't complete the project without them, they are called out as a separate category because regulations are subject to lobbying and fickleness from governments and regulatory authorities. It may be possible and would be desirable to separate regulatory changes into those which will not change during the life of the project and those which are subject to regulatory review, appeal, or a change in government or regulating authority. The dates of any possible changes should be noted, so that we know when the item ceases to be subject to change. For example, if an election and change of government is known to affect a requirement then the election date should be tagged with the requirement definition.

As we move up the scale through cost reducers, spoliers and differentiators the amount of uncertainty about the requirement changes and hence the greater the risk that the definition of the requirement will change or that the need for the item all may change. We do not want to work on items that will be deleted from scope or that may be subject to significant changes. So these items should be deferred until later in the project.

Create Sequencing & Capacity Allocation Policies

If there is no risk that the project delivery date will be brought forward then we would sequence all table stakes, then all cost reducers, then all spoilers, then all differentiators. Regulatory changes would be scheduled as soon as we know they are no longer subject to change prior to the project delivery date. Projects where there is no risk of the delivery date coming forward are usually regulatory in nature or are related to a seasonal business or industry, common in the clothing, apparel and fashion industry, for example, or a major event such as the World Cup or Olympic Games. So if we have a project of this nature, and we have our requirements assessed for the market risk of change then we can write a simple policy definition for sequencing work through the kanban system. Items of the same category, e.g. cost reducers, can be done in any order, there is no risk management benefit from prioritizing them or sequencing them in any finer detail. This is true only if market risk of change is the only risk dimension we care to manage. Typically we would have other risk dimensions to consider so the policies will be more complicated than described here.

If there is a risk that the delivery date may be brought forward, typical of commercial product or service projects, then we should hedge this risk. The most value is in the differentiators or the spoilers, depending on strategy and market positioning, so we should hedge the risk of moving the delivery date forward by allocating capacity in our kanban system to higher value, higher risk items. We can facilitate this by segmenting our requirements. If our product or service targets multiple market segments or personas then each requirement should be tagged by the segment or persona it supports. We should ask our marketing people to prioritize or sequence the market segments or personas based on their preferences - most likely based on current market objectives. If for example, we hope to grow our market share by targetting teenagers, then the segment or persona for the teenager will be given priority. In addition, we should create policy to alllocate capacity on a sliding scale during the project lifecycle. For example, we may want 80% allocated to table stakes initially, falling to 0% before project completion, while only 10% is allocated to differentiators at the beginning, growing to 80% by the end of the project. This capacity allocation affects the kanban in the system and provides specific pull signals telling us what type of requirement to pull at any given time.

Risk is a Multi-Dimensional Problem

Of course, this blog post is only looking at a single risk dimension and risk is a multi-dimensional problem on most projects. The qualitative risk assessment framework fills a full day of the Managing Risk Masterclass and some of its contents fill around 25% of the Advanced Practitioner curriculum classes on Scaling with Kanban, or Project Management with Kanban. There is a lot to learn and a lot to consider in this field, so typically, our scheduling policies are more complex than decsribed above. For example, we might consider technical risk. If an item is a differentiator but also technically risky - we have never done it before and don't know how to do it - then we might have a policy that states items of this category should be split into two. The first should be a prototype (or "spike") to determine viability, this item should be scheduled early in the project to provide us with useful information. The second item from the split should be the high fidelity feature based on the new technical capability. This differentiating feature should be deferred until late in the project.

Policy-based Scheduling is More Powerful than Traditional Backlog Prioritization

There is no need to sequence every item in the scope of a project. In fact individual items should not be sequenced. A small set of policies based on risk assessment will guide selection of items as kanban signals indicate capacity to start an item. This set of policies is easier to maintain than a prioritized project backlog and is more powerful as a risk management tool. It is easy to explain why a policy was written and if circumstances change, it should be self-evident when policies need to change. Policy changes will immediately affect new selection decisions for the kanban system. There is no need to maintain the project backlog. All that is required is that items in the project scope are assessed for risks at the time of commitment and that the project scheduling policies are maintained based on the risk management approach advocated by the project manager.

Project Management with Kanban Training

This blog post can only give you a flavor of how we do scheduling, sequencing and selection, with kanban systems for project management. To learn the full power of these techniques consider taking our Project Management with Kanban, Advanced Practitioner level training, of the Managing Risk Masterclass. For full details see our training listings.

Full Series

Part 1 - Project Management with Kanban Overview

Part 3 - Project Forecasting

Part 4 Risk Review and Blocker Clustering

Comments: