Manage the project end-to-end life-cycle with Kanban

Title: Manage the project end-to-end  life-cycle with Kanban (previously was “Accelerate the project flow with Kanban”)

Catalogue: Lean Adaptive Management – Addressing project management challenges with Kanban

What this pattern is about: the project life-cycle – from idea to implementation; the communication bottleneck – balancing value discovery and value delivery; tailored project management for linear and iterative work flows

Focus on delivery

Story: Joe has recently been assigned a project in the business area that he is an expert in. He works for an international company. The project life-cycle that he needs to comply to, states that a user requirements specification (URS) is required before project development can start. So he has worked very hard to produce this URS. Now that he is in the process of seeking approval of the URS, he encounters a lot of resistance. The IT manager claims that he does not understand the URS; other stakeholders are not eager to give approval. According to compliance rules the project cannot start. In practice however – because of the pressure to deliver – IT has already started on the functional specifications. With all the discussion going on about this, somehow everybody is losing sight of the ones that matter most for this project … the users that later on will have to operate the system. Joe talks with his colleagues about the situation. It seems that many have similar experiences. It seems that the harder pressed they are to start the project the longer it takes to finish it.

Every project has a life-cycle. In many project organizations the project life-cycle has a formal character. In such cases, projects need to comply with it or tailor it to the project’s specific needs. In other project organizations, there seems to be a de-facto life-cycle, be it linear or iterative.

In theory, the life-cycle is there to prevent mistakes that will cost dearly later on in the project. In the linear life-cycle, we have stage-gates to prevent that we take short-cuts and ensure the quality of early life-cycle stage deliverables. In the iterative life-cycle, we have iterations because we want to avoid that big developments are done on unvalidated assumptions (assuming that these assumptions can only be validated by means of a working product). In theory, the life-cycle is there to ensure that value is delivered to the customer and users.

In practice, things turn out differently. Excellent delivery alone does not make success. In many project organizations, the project life-cycle starts when many important decision have already been taken. In many cases, the whole process of value discovery (understanding what value to deliver), is not covered in the life-cycle. Or, it is covered with much less detail and understanding. Generally, we tend to sub-optimize by overly focussing on the delivery side and not sufficiently involving upstream and downstream stakeholders (and ultimately the customers and users). It rarely happens that, the whole workflow is covered end-to-end, from idea to implementation. This applies to linear/waterfall life-cycles as well as to iterative/agile life-cycles.

From idea to implementation

But there is an even bigger issue. It has to do with  the tendency to think in one-size-fits-all solutions. For those that apply a linear life-cycle, all project must follow a linear life cycle – we need to think things through before we start. For those that think in iterations, all project must be iterative – focussing on delivery and feedback, here and now. In the ideal world, both types of life-cycles can work on their own. In practice a lot of energy is wasted in window dressing and using the wrong approach for the wrong situation.

It is no coincidence (in my opinion) that those involved in value delivery (developers, engineers, testers, etc.) are more inclined towards an iterative life-cycle and those that are involved in value discovery (business analysts, product managers, product marketing, etc.) are more inclined towards a linear life-cycle. The reason is the different time perspective of long-term value discovery versus short term value delivery. In practice this turns out to be a serious communication bottleneck. How many organizations have you encountered where there is a huge backlog of items to be developed – to the frustration of both the business and the development team -, but that development is continuously working on the basis of ill defined requirements because no one has the time or intention to turn these ill defined backlog items into well prepared work items? Project organizations need to be able to combine the long term with the short term and the life-cycles that are associated with it.

A chain is as strong as its weakest link. Project organizations need to manage the flow of work from end-to-end; from idea to implementation. The project life-cycle must include both value discovery as well as value delivery activities. The work that is involved with value discovery must be synchronized with the work that is involved with value delivery. And we need to combine value discovery and value delivery into both linear and iterative workflows.

End-to-end flow

Practically, we can set up Kanban boards for both value discovery and value delivery. The focus of the value delivery Kanban board is on managing the work in progress, the lead and cycle-times and helping the delivery team to self-organze. The focus of the discovery Kanban is on stimulating the engagement of upstream and downstream stakeholders (and users and customers), gaining an understanding of the priority of the most valuable work, and ensuring that all delivery work is well prepared. In the end the discovery Kanban must produce requirements with a clear value and priority in its output queue. Both types of Kanban boards are linked through a pull system. Delivery teams pull work from the discovery Kanban thereby signalling to the discovery teams that more work needs to be prepared in terms of e.g. requirements (but not to much of course).

The end-to-end Kanban as described in the previous paragraph is sufficient to manage the flow of routine work in a project or project organization. This includes maintenance tasks, standard services, routine performance improvements, routine enhancements, etc. The type of work where all requirements can be made clear upfront, the business case is straightforward because only one stakeholder is involved, the work can be executed by an independent team and there are no exceptional technical challenges. It all fits well in the current functional, technical, and business architecture. Work can flow linearly from discovery to delivery.

Linear flow

Not all projects are routine, of course. Sometimes more complicated work needs to be tackled: work where not all requirements can be made clear upfront, the business case is complicated because different stakeholders are involved, different teams are involved, and different experts need to be involved to clarify the business case and to help tackle technical complexities. Work can not simply flow linearly from discovery to delivery. The risk mandates iteration between value discovery and value delivery (iterative flow).

Iterative flow

Complicated projects start out in the same way as routine projects in the discovery Kanban. They are a combination of individual ideas that turn out to be too complicated to be delivered in one go. For complicated projects both the life-cycle of the project as a whole needs to be managed as well as that of individual work items. Work is managed on different levels: at the portfolio level the flow of projects is managed, at the individual project level the flow of project work items is managed.

Managing the end-to-end flow with Kanban

Story: Joe has set up a Kanban board for discovery. This Kanban board visualizes the flow of ideas, concepts and requirements. The different columns of the discovery Kanban represent different steps in the engagement with users and stakeholders. There is a cadence with which ideas are turned into concepts and concepts are turned into requirements. He has set up trigger points to ensure that at all times enough requirements are prepared to go into development (but not to much). As a result, Joe anticipates the pull of development but does not anticipate to much. At organizational level there are two levels of Kanban boards now: the portfolio level Kanban board in which ideas are collected, concept are prepared, and projects are qualified (routine or complicated), and the project level Kanban boards in which ideas, concept and requirements are processed for individual projects.