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.

Posted in Uncategorized | 4 Comments

Addressing project management challenges with Kanban

The new, new thing

Story: Software developers and IT people are a strange lot. Not so long ago they argued that the best way to manage (software) projects was Scrum or some other agile development approach. Some of them were even pretty fanatical about it (and still are). Now they are talking about Kanban. As a veteran in the industry, my friend and colleague project manager, David, has already enough trouble bridging the gap between these agile development teams and the rest of the organization that is not so agile (for good or for bad reasons). He is not sure whether to follow this Kanban thing or not.

Is Kanban just the next fad? The new new thing?  Is it limited to IT/software projects? Or is there something more to it? In this and subsequent blogs, we describe a number of patterns for managing projects with Kanban. These patterns have been discovered in real life application of Kanban in project organizations (both IT projects and non-IT projects).

The patterns we describe here can be understood and put into practice independently but their full potential is only realized when they are used together. Taken together they are a crucial component of what we call lean adaptive management. The patterns explicitly show how project management can be adapted to the realities of dealing with the complexities of projects in the real world (as opposed to the idealized world in which all projects succeed). These complexities include shifting priorities, multi-tasking, communication problems, and resistance to change.

Patterns of managing projects with Kanban

Story: Now things are much clearer. After studying the patterns of actual use of Kanban in project organizations, David understands how Kanban actually helps to address project management challenges: identifying and managing resource bottlenecks, identifying and overcoming communication bottlenecks, identifying and overcoming people bottlenecks. Maybe Kanban and project management make a good marriage?

As each of these patterns are in full evolution, we welcome all comments, feedback and suggestions for improvement. In subsequent blog posts we will cover the following patterns:

Manage project and functional teams 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

Accelerate the flow of projects 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

Manage change with Kanban

What this pattern is about:

  • project management maturity;
  • the people bottleneck – resistance to change;
  • evolutionary change with Kanban
Posted in Uncategorized | Leave a comment

Lean Adaptive Management

Some organizations work in a simple, stable business environment with simple, stable and consistent business goals. Other organizations have to deal with a complex, fast changing business environment where business goals may be contingent or even contradictory. Our current models for improvement are well equipped for simple and stable business environments but fail to cope with the complexities of today’s fast changing business. We need to move beyond the current single- and multi-model improvement theory that – in practice – fails to go beyond local one-shot point improvement. Current improvement theory fails in practice for various reasons:

  1. it leads to local optimizations where upstream and downstream stakeholders (and ultimately the customers and users) are not involved;
  2. it is based on one-size-fits-all processes that only fit the needs of “average” projects and teams but no single project or team in particular
  3. it is built on few successes that are build on a graveyard of failures because improvement is either exclusively driven from the top or does not move beyond champion teams.

In order to tackle the above issues organizations need to work on three fronts at the same time:

  1. End-to-end flow: Use lean principles and practices to create flow in the end-to-end value stream starting from initial ideas up until actual implementation. The end-to-end-flow needs to take into account both value discovery (understanding the value) and value delivery (delivering the value).
  2. Tailored project management: Use adaptive principles and practices to differentiate between developments where the value is clear enough to go almost directly from value discovery into value delivery (linear flow), and developments where the value uncertainty mandates iteration between value discovery and value delivery (iterative flow).
  3. Organizational maturity: Create a management culture that works both bottom-up and top-down. Create a continuous improvement and high-maturity culture from the bottom-up. Use models and model appraisals as a yardstick to measure organizational progress top-down in order to avoid that local improvements get stuck locally. And most of all, use tailored project management to simultaneously manage bottom-up and top-down improvements to match complex business goals.

The concepts of end-to-end flow, tailored project management and organizational maturity interweave into a power trio that is adapted to tackle the most complex business challenges.

Posted in Uncategorized | Leave a comment

Putting projects central

People like to discuss the pro’s and con’s of different models of project management and product/service development. Often they do so with much animo. Sometimes even with some fanatism. These discussions put models in the centre of attention. Just take a look at different conferences, seminars, discussion groups … Often the central theme is a specific model.
It would be nice to see that, as a community, we exhibit the same enthousiasm in discussing project differences. What characteristics make one project different from another?Which different classes of projects can we identify? What does this mean in terms of different approaches? This would put projects in the centre of attention. After all most of us are in the business of delivering projects, not models.

So, how do we differentiate projects? Many factors exist: size, technology, culture, novelty, and many more. We identify, two key differentiating factors – business uncertainty and user involvement – and projects are grouped into four project archetypes:

  • Routine projects: Implementation of standard service or product or routine performance improvements
  • Development projects: Development and delivery of non-standard products or services
  • Discovery projects: Potential breakthrough innovation of products or services or process
  • Sensitive projects: Development of technology or large infrastructure or large organisational change

Each project archetype has its own set of challenges that requires its own unique approach:

  • Routine projects require increasingly efficient delivery of quality;
  • development projects require the co-ordination of experts and the management of risk;
  • discovery projects require dealing with unknown unknowns; and
  • sensitive projects require ways to deal with possible conflicts between the stakeholders.
Posted in Uncategorized | Tagged | Leave a comment

Dealing with conflicting business goals

One of the 1st steps in starting a business driven improvement programme is to elicit the business goals. In the ideal(ized) world of improvement theory, standards and models, these business goals are clear, unambiguous and independent. In this idealized world this often boils down to some variation on faster, better, cheaper and depending on what your background is, you want it in a more predictable way or a more agile way.

Over the years, however, it has become increasingly clear to me that in the real and complex world, improvement programmes inevitably start with conflicting business goals. Examples include:

• we want faster delivery but also ever-higher quality,
• we want creativity and innovative products while being compliant to a growing number of standards,
• we want more reliable plans while expecting an increasing flexibility in dealing with changing priorities, etc.

This is the reality where most business are in.

Rather than trying to avoid this conflict, or do away with it as an anomaly, we need to embrace it. The cause of failure of improvement programmes could well be the lopsided view they have on the business goals. When the focus is on higher predictability, conformance, cost-control, the result is a alienation of the part of the business that actually needs more flexibility, resilience, and entrepreneurship. When the focus is on flexibility, resilience, and entrepreneurship it is the other way around.

Posted in Uncategorized | Leave a comment