This approach is often tied to Agile methodologies, but it has actually been around far longer. I was using a modified Kanban project scheduling tool in the 1980’s. The tool shows the relationship between scope schedule and resources. Like the Gantt chart, it is very effective for managing the day-to-day status and tracking. And also, like the Gantt chart, it is a tool that can be used with many different project management methodologies.
This tool works best for those projects where many different deliverables go through similar steps or activities. The Kanban schedule is set up as a matrix. The vertical side of the matrix is the list of project deliverables. The horizontal side is the steps or activities in the project. Normally, at the top of the matrix, the level of resources available for each step is listed either in terms of the number of individuals or the number of deliverables that can be actively worked at one time. See the diagram below.
Kanban scheduling relies on two important principles. The first is that it is “pull” scheduling, not “push” scheduling. This means that a deliverable does not move to the next step until there is a resource available to work on it. As soon as the resource completes a deliverable, it pulls the next deliverable from the preceding step. That way a step does not become glutted with many deliverables all hung up at a bottleneck.
The second principle is that it is a “visual” scheduling tool. The “pull” indicator is visual and the status of how many items being worked on at one time is also visual on the matrix. In addition, I normally will change the cell color of the deliverable and the step to show what is being worked on and what is completed. Visual control normally leads to improved project team communication because it is simple to understand.
There are two weaknesses with using Kanban scheduling. The first is that it is difficult to translate the schedule to a calendar. The Kanban schedule is a matrix. Often the matrix will have dates for each step of each deliverable, but it is difficult to take a table of dates and picture what is happening on a calendar. That is why I normally will also use a calendar-based Milestone chart when using a Kanban schedule.
The second weakness is that it is very difficult to track inter-relationships between deliverables. If the deliverables are separable that is not a problem. If there are numerous points of interaction between deliverables, the ability to pull can be confused. In that case, the network diagram is a better scheduling tool because it shows those relationships and allows the project team to calculate a critical path.
Planning with Kanban
So let’s talk through how a project plan would be represented using a Kanban schedule. First create the list of deliverables – this is usually derived from the scope statement or project contract. Then determine the categories of activities that must be accomplished on each of the deliverables. This is the same type of activity you would do when developing a work breakdown structure. With these two pieces you can build the matrix. Next, determine the resources capacity you have for each activity type. Finally, estimate the amount of time required for each deliverable and estimate the dates when each activity will end for each deliverable. Place that date in the appropriate cell of the matrix. See the diagram below.
Managing Project Progress with Kanban
The Kanban tool is an excellent tool for managing day-to-day project activities. Thanks to the visual control aspect, it is easy to see what is underway, what is complete, and what is coming up next. Because I use cell colors to indicate activity status, the current project status is easy to see. Also, problem deliverables or problem steps will quickly “jump out” from a review of the matrix.
In the diagram below it, the present date is July 25. It is easy to see that Deliverable #7 is behind schedule. This is a major issue on the project and should be receiving the project manager’s focused attention. In addition, the “Update/Debug” step is becoming a bottleneck. There are five deliverables that could in process at that step, #3, #4, #6, #10, and #11. However, the capacity is only to work on three, so deliverables #4 and #11 are not being worked on by anyone at this time. So far it is not a major bottleneck, but deliverables #2, #8, #12, and #13 are in work in the previous activity and could be turned over to the update/debug queue soon.
The Kanban schedule tool can be very useful for some types of projects. It combines scope, schedule and resources into one easy to read visual display. If this tool is not currently in your project management toolbox, you should consider adding it.