Traditional Project Management focuses on 2 areas.
1. Tasks complete and calculate % project complete based on this roll up score.
2. Control flow of tasks to manage resources and dependencies.
Kanban addresses these 2 areas differently and in my opinion more correctly.
1. Task complete is not equal to % Project complete. It is possible that we burn money on completing tasks, but have failed to realize output. If you look at the board, the % Project complete is a function of your
(Release Ready Queue count - Total queue list count)/total queue.
**Total Queue list should exclude release ready queue count. Ignore negative sign while looking at %.
2. It is important to optimize resources time and hence instead of managing task dependencies through dates, manage on keeping the queue active and moving. This way, resources can pick up tasks in queue after they finish the first job. This frees up tight dependency waiting lines thereby boosting productivity for both teams (in dependency chain).
Release control on tasks completion and focus on managing queue. This means that instead of saying "Finish task by a certain date" , you will focus to say "Move deliveries to final queue by a certain date." Working backwards, you will start to focus on moving current tasks to next queue before the next queue dries out and the current task queue overflows with backlog.
It is a perfect pitch to have tasks waiting for resources than resources waiting for tasks. Resources working on tasks earn revenues. Resources not having tasks are cost leaks.
Do not control resources working time (there are unproductive hours in a day for every one), rather direct energies to control time spent on tasks. This means that instead of checking if a resource is punching job card for 9/10 hours, check and control if Task A consumes more time than estimated and how it affects the queue build up Velocity.
Kanban charts give away a lot of answers while we follow them than chase problems for solutions.