Title: Manage project and functional teams with Kanban
Catalogue: Lean Adaptive Management – Addressing project management challenges with Kanban
What this pattern is about: the project organization – from functional to projectized; the resource bottleneck – multi-tasking and shifting priorities; manage teams with service level agreements based on classes of service
Story: My friend, and colleague project manager, David is managing a customer project in a product development company. He is responsible for making sure that the project delivers what has been promised to the customer. He is assigned a team of software developers. While David is on-site with the customer, the software team is working on the project. Or so he thinks. When he checks in with the software development team, he learns that other ‘high priority’ tasks have occupied ‘his’ team and the team has not been working on the project as promised.
The above story is a typical story in project organizations as they struggle to get organized. Should the project organization be organized according to functions or disciplines (functional organization), should it be organized according to projects (project organization) or something in between (matrix organization)?
In an ideal world where priorities are stable, single-tasking is the norm (i.e. working only on one project at the time; working in only one function at the time) and people (are able to) respect commitments, each of these models might work very well.
The fact is that we do not live in the ideal world. Far from it. The difference between the ideal and the real world is that in the ideal world we can depend on rigid boundaries (every milestone is a deadline, no tasks outside the project, every variation is an exception) while in the real world, rigid boundaries tend to break, and we need to work with flexible boundaries.
In the real world, priorities tend to change – in many cases, even for good reasons. Some projects encounter problems and other projects go smoother than initially envisioned. Sometimes opportunities present themselves and no time can be wasted to capture the opportunity. Sometimes what is thought to be an opportunity turns out to be a fad. Project priorities need to be managed in a dynamic way and the organization needs to be able to cope with changing priorities without this turning into chaos, frustration and arbitrariness.
In the real world, division of work is messy because of dependencies and natural variation in the work. Projects do not have a start date where suddenly all of the work starts and an end date where all of the work suddenly stops. Projects overlap and people need to divide their attention between starting projects, projects in full execution, and past projects. Additionally to that, team members are not pluggable components, not even team members in the same function. Team members cary a history of past projects, past functions and past experiences. So work can not be perfectly divided between project teams (i.e. all work is contained in the project team and project team members have no tasks outside the project) or functional teams (i.e. all work can be perfectly distributed over the functional teams and no work is done outside the function).
Project organizations need to be able to manage multi-tasking without this turning into accumulating delays, lack of commitment, and uneven distribution of work. This is what Kanban is all about. It is about managing a smooth flow of work within flexible boundaries (shifting priorities; managing multi-tasking; managing the natural variation of project work).
With Kanban work is not pushed onto teams. Rather, teams pull work based on work in progress (WIP) limits. WIP limits are an expression of the amount of multi-tasking that is allowed in the team. WIP limits express a flexible boundary in which the team can organize itself: some multi-tasking is allowed but not to much.
As teams measure lead and cycle-times, and improve so that lead and cycle times become more stable, they can confidently make promises about how long it will take to start a work item and how long it will take to finish it. However, teams do not make a promise about every individual item that comes in (a rigid boundary), only about the “average” item (a flexible boundary).
Finally, Kanban teams use flexible priorities. Priorities are not based on “importance” but on time-criticality as typically expressed in different classes of service: expedite, fixed-date, standard, intangible. Classes of service create a flixble boundary for the Kanban team to manage their commitments (see David Anderson’s LESS speach for more details on how this works).
In practice, project management with Kanban means that, as a project manager, you can work with a project team, functional teams, or a combination of both, where each team has a service level agreement that you can rely on. The service level agreement is rigid enough so that project commitments can be lived up to, and flexible enough to take into account the messy-ness of the real world.
Working with a Kanban team
Story: David is now working with a new project organization that is based on Kanban teams. He has a core project team that uses Kanban to manage all their project tasks, but also to manage occasional duties for upcoming or past projects. He works with functional teams that use Kanban to manage the work that is coming from several projects at the same time. At the start of the project, capacity for the stream of work is reserved with each of the Kanban teams based on the time-criticality of the project. During the project, he authorizes work to the Kanban teams by replenishing their input queues.