Manage project and functional teams with Kanban

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

Team commitment

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).

Organizational entropy as a result of messy work division

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).

Organizational blueprint based on service level agreements

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.

This entry was posted in Uncategorized. Bookmark the permalink.

4 Responses to Manage project and functional teams with Kanban

  1. Wim Bollen says:

    it allows also balancing between committed (project/service team) resources and involved (reviewer…) resources, not?

    • Indeed. I was perhaps not entirely clear on this. In every project you have team members that are really committed to the project. They spend most of their time on the project with few other tasks. Other team members are only involved. They spend some of their time in the project, and in different other projects or operational tasks as well. To cater for both types of team members, we need teams with flexible boundaries.

  2. Hi Patrick,

    Given that we’re talking about a functional team (of whatever size), I think it’s worth pointing out that we can apply the same classes of service thinking to projects as well as features. Not all projects are the same!

    Talk soon 😉

  3. randkw says:

    My organization designs large electric generators for use in utility power plants. In hardware design, we find it necessary to have projects whose full scope must be delivered on a scheduled basis. In the past two years we have achieved significant throughput increase and on-time delivery success using critical chain project management. Project task priorities within and across projects are derived from the rate of buffer consumption in the project plans. Unfortunately, non-project work items of varying size form about 50% of the demand on our resources. Non-project work is often prioritized by due date, but some task results are urgently needed and some have negotiable due dates. Non-project work is the camel that sticks its nose into the project tent. Unless it is managed, it will take over the tent and disrupt any project management system. While CCPM provided a system-level control on project WIP, it did nothing to manage non-project WIP. We are now applying Kanban with Classes of Service to integrate the management of both project and non-project work. Initial results of the combined use of CCPM and Kanban look promising.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s