From Stocks to Flows (and from portfolio to end-to-end)

At LSSC12, Mike Burrows organized an evening meeting on “portfolio stuff” (sic). He is reporting about this on his blog.

In his blog he wonders whether the name “portfolio management” is the right name as it carries the bagage of failing approaches.

I agree, the term portfolio carries a couple of connotations that we want to get rid of:

1) thinking about a project portfolio as a stock – when we talk about a project portfolio people tend to think about the portfolio as a stock that can be valued; they talk about optimizing the value of the portfolio, etc. Rather than thinking about the project portfolio we need to start thinking about it in terms of flow.

2) project portfolio thinking emphasizes functional/silo thinking – in your organization, do people talk about the “IT project portfolio”? The “development project portfolio”? If so, then you know what I am talking about. Talking about the “IT project portfolio” emphasis the IT function as a silo. Rather than that, we need to think end-to-end value stream.

This leads me to the advice, drop the name “portfolio” talk about end-to-end flow. Let’s not talk about “portfolio kanban”; let’s talk about end-to-end kanban!

The opportunity is not in going up in the hierarchy of the development silo. The opportunity is in broadening our view from “development kanban” to “end-to-end kanban”. What happens upstream? How can we support the upstream “business value discovery” process with visualization, pull, flow, collaborative improvement? How can we support the downstream “implementation and validation” process with visualization, pull, flow, and collaborative improvement?

What does this end-to-end flow look like? What items are flowing? Just work items? Or is it options (as in real options) and commitments? Is it limiting “work-in-progress” only? Or is it also ensuring “minimal options”? Is it collaborative improvement within “development” or is it collaborative improvement across the end-to-end?

I was not at the LSSC12 and the “portfolio stuff” meeting, so maybe I am repeating what was said already there. Still I thought it worthwhile to put in my 2 cents to the discussion.

Posted in Uncategorized | Leave a comment

Lean Programme Transformation


For a while now I have been eager to look at the bigger picture of Lean and Kanban beyond the pure software development context. My inspiration comes mainly from the work of Alan Ward, Micheal Kennedy, John Shook and the likes on Lean Product Development and A3 thinking. The challenge was to apply it to a business/IT context. Recently I have had some opportunities to explore Lean and Kanban concepts in the context of Large Transformation Programmes (abbreviated to LTP in the rest of the blog).

Large business and IT transformation programmes represent a large expenditure with a substantial impact on the business and IT systems. Uncertainty in these programmes is high – both on the side of expected benefits as well as on the side of the capability of the organization to deliver the programme. Hence large transformation programmes are often plagued with overruns in budget and schedule, quality issues and in the end not delivering the aspired benefits. Due to economic and market reasons, organizations are starting to show less tolerance for overruns and quality issues in such programmes. It is time to explore how lean thinking can transform large transformation programmes.

Situation analysis

The traditional cornerstones for delivering LTPs include: stage gate project life-cycle, division of work in work-streams, some kind of portfolio management to release projects in the organization. These traditional cornerstones have proven to be deficient in the following ways:

Largely linear project life-cycle with stage gates gives rise to long project lead times (spending a lot of time in analysis and re-analysis) and loopbacks in later project stages.

In one example the LTP spend an additional 9 months in analysis. Even after doing a thorough analysis of all the business processes, the different (application oriented) work-streams felt the need to re-do the analysis from an application perspective and taking into account the capabilities of existing applications and a package application that was going to be implemented. Even after all this analysis it was hard to assess the impact of the transformation for the business people involved.

The programme also suffered from loopbacks. Work streams were de-scoped late in the project because of time pressure, wasting work that was already performed. Of all the (+20) business process that were analysed, only 5 processes were deemed critical. The work of the architecture team was largely neglected by the work streams resulting in the need to reverse engineer the (as-build) solution architecture. The purpose of the programme was to build an architecture that could be reused across business lines and regions. Even before the first implementation it was clear that much rework would be needed before going to the next implementation.

Work that is organized in technically driven work-streams ( roughly corresponding to existing delivery teams) giving rise to silo thinking, fragmented knowledge, integration problems and resistance to change.

In traditional programmes,  separate work streams are delivering in organizational silos each with their own goals and objectives. This means that goals and objectives of the work-stream are often too remote from the programme goals and objective. Also, the know-how and responsibilities about the solution is fragmented (in silos), without end-to-end ownership. Because each of the work-streams is working in a silo, integration proves to be a problem. Because non of the work-streams actually delivers business value in itself (only the integrated solution does) no value can be delivered before all integration problems are resolved. It’s an all or nothing solution making it hard to manage the programme towards its aspirational budget and schedule. Moreover it means that the business can expect a big change when the solution is implemented. Business is not ready for this big change and may never be ready to truly accept a big change like that.

Releasing projects into the organization based on “priority” and resource availability gives rise to reinvention of knowledge and duplication of effort.

Similar transformation projects are simultaneously started in different lines of business or in different geographical regions because of time pressure. Because transformation projects for each line of business are started in parallel there is no opportunity to learn across these projects. Even when projects are started sequentially, organizations do not have the capabilities to learn across projects.

Lean transformation

So what can lean thinking contribute to solving the above problems. We will look at the following pilars of lean and how they apply to managing an LTP:

  • Value
  • Pull
  • Flow
  • Standards

Focus on value

The purpose of a transformation programme is not to deliver IT systems but to improve the business. The business is struggling with a problem. Let’s say that we are a manufacturing company. Maybe inventories are too big (and costly). Maybe delivery times are too slow (and not to the satisfaction of the customer) or too variable. Probably, performance in both dimensions is unacceptable. The main challenge for the programme is how to fundamentally improve the business. In the current state of business improving in one dimension (inventory) leads to unacceptable performance in the other dimension (due date performance for delivery). Fundamental improvement means to improve on both making inventories smaller and delivery times shorter. Typically we can capture the business problem in a trade-off curve as shown below.

Pull not push

Pushing one overarching, one-size-fits-all solution to our business problem has proven not to work. The situation analysis has shown that it leads to programmes that are hard to manage towards budget and schedule, a business that is not ready, and probably not delivering the improvement that was envisioned. At worst the programme cascades into failure – the technical problems become to big and resistance to change kills the programme off.

Value-driven programmes allow the business to pull small increments of value. They work in small steps allowing the business to learn what works and what does not work. As confidence grows (and also knowledge), bigger and bigger increments of change can be undertaken.


A value-driven programme is organized around A3 sized business improvements: business improvements that can be described and visualized on an A3 sized paper. (an example A3 is given at the bottom of the blog post). Each A3 sized improvement addresses a different root cause of the business problem.

Each A3 sized improvement also provides an opportunity for learning. At the start of the programme we have unclear visibility about what is realistic and what is not realistic business performance. Improvements need to be carefully planned to provide maximal learning opportunities about the trade-offs between the different dimensions of business performance.

As the programme progresses, we need to validate what has been delivered before starting new work. We can design a simple Kanban system to manage the flow of improvements.


With the above steps we have actually started to implement the plan, do and check steps of the PDCA cycle as show below.

As the cherry on the cake we now turn our attention to the act step. In the act step of the PDCA we need to make sure that what has been learned and developed in previous incremental improvement in the programme is made available for reuse for future incremental improvements. We need to scale up what works well and scale down what did not work well.

Examples of what needs to be captured and standardized for future reuse includes:

  • Business policies and procedures
  • IT systems and solutions
  • Delivery and delivery management capabilities

Summary A3

The following A3 summarizes the Lean Transformation of Large Programmes.

Posted in Uncategorized | Leave a comment

Using Cynefin to make sense of projects

Since a couple of years we have been using Cynefin to help our customers to make sense of the different domains of projects they are executing. The motivation for doing so, is that we strongly believe that the one-size-fits-all approach that dominates most of the thinking today, is a major source of project failure.

In general we have found that most organizations do have projects that very much align with the different Cynefin domains. These domains include the following types of projects:

Routine projects (ref. Cynefin “simple/known” domain)

These are projects that the organization is executing on a very regular basis with very low risk and high predictability. The challenge in this domain of projects is not in the delivery of a single project but the increasingly efficiently delivery of many routine projects with increasing levels of quality. Consider for example a web-site development company that delivers web sites on a very regular basis (1 per week) with a relatively standard process and within relatively standard constraints. The organization has developed a routine for delivering such projects. It needs to ensure that it is increasingly efficient and quality is continuously improving. Often times the work is routinized to the extent that it is considered to be a continuous service rather than individual projects.

Of all “project management” approaches, Kanban is most appropriate in this domain. The Kanban properties of visualizing the workflow,  limiting work in progress, measuring and managing flow, making process policies explicit, using models to recognize improvement opportunities are critical in the routine domain.

Extension projects (ref. Cynefin “complicated/knowable” domain)

These are projects that are in extension of the organizations current capabilities and expertise. While there may be a certain level of uncertainty involved, this uncertainty can be assessed by experts in the organization. Uncertainty may be both on the side of the value of the project (do we know what we need to build?) as well as on the side of the execution (do we know how to build it and do we have the capabilities?). Most importantly the risk can be assessed and managed. Typical for this project domain is also that risk can be managed by close interaction with the customer (i.e. there is a trust relationship that allows close interaction between project team and customer and iteration to a solution). Many development projects are in this area if they are properly set up (if they are not properly set up, they will end up in the sensitive domain below).

In the domain of extension projects, project managers need to be equipped to manage project risk by means of iterative delivery of the project results. Kanban can be extended into this domain as explained in the post on end-to-end project cycle.

Emergent projects (ref. Cynefin “complex” domain)

These are the projects where there is a large uncertainty about the value of the project (we may not even know who the real customers are) but we have ways to do experiments with low cost of failure and where we can quickly learn from these experiments. Project objectives are emergent based on direct customer feedback. True innovation projects that are properly set up fall into this domain.

In the emergent domain notions like iterative customer discovery as advocated by the lean start-up community are critical.

Sensitive projects (ref. Cynefin “chaos” domain)

These are the projects where there is a (lethal) combination of uncertainty about the value of the project and the execution of the project (how to deliver the value). In other words there is a combination of human uncertainty and technological uncertainty. Typically, these are projects surrounded by conflict, disagreement and ambiguity. It is exactly the combination of human uncertainty and technological uncertainty that is the breeding ground for rapidly cascading failure in these projects. Typical projects in this domain are large projects with substantial re-architecting of the existing infrastructure or capabilities.

Many development projects (that should be in the extension domain) also end up in the sensitive domain because of lack of trust between the customer and the supplier or lack of knowledge of how to set up such projects (E.g. setting the project up as a waterfall instead of iterations). Often times organizations move themselves into the sensitive/chaos domain by not properly aligning themselves around a common purpose. Whatever the reason for this – lack of trust, lack of vision, lack of management know-how -, in the end it leads to local optimization.

Still, often times the chaos/sensitivity comes from external factors. As in the large re-engineering project that was mentioned above. The organization is confronted with a rapidly changing technology landscape and needs to adapt its (large and complex) software to that and at the same time there is a high pressure to deliver new features as the competitive pressure in the market grows. It needs to change the engine of the car while driving at 100mph so to speak.

This seems to be more and more the new normal. It seems that in today’s business environments, dealing with contradictory and contingent goals (or objectives if
you like) can not be done away with as an anomaly but are an essential part of doing business. This poses – in my opinion – a serious challenge for how we think about management and project management in particular as our dominant models seem to rely on clear, consistent, stable goals.

In the domain of sensitive projects, project managers need to understand how to deal with contradictory goals, cascading failure, etc. This requires an insight in complexity models just like Cynefin which brings us back to the topic of this post – the need for project managers to take a broader view and abandon the one-size-fits-all approach. Herein lies the fundamental next step in delivering projects more successful.

Posted in Uncategorized | 1 Comment

Understanding value

Title: Understanding value

Catalogue: Lean Adaptive Management

What this pattern is about: business alignement around value creation, the adaptive cycle of products and services, understanding value through a sense making framework

Maximizing value

Story: Wim and his team have worked hard to charter the upcoming major development projects for their next product release. These projects represent the majority of the product development investment their company will make in the next 6 to 12 months. Now they have a feeling that everybody has a shared understanding of what they are investing in. The management team recognizes that they now have an excellent view on what is going to be developed. Still they find that they need a clearer view on the “why” of all these projects. They want to get a better – and measurable – view on the benefits/returns that these investments will bring. In a workshop with the product manager and the sales manager it becomes clear that despite the fact that there is agreement about the choice of individual projects, sales and product management are not aligned on the big picture. Sales is frustrated as they have the feeling that they don’t get a clear message from development – e.g. they get the message that a certain product capability is developed, and then suddenly, if they want to market the capability, development is very cautious about it; apparently the capability was not developed to the full extent, or was it? On the other hand development and product management are frustrated. They feel a lot of pressure from sales and marketing – we need this and that feature to go to this and that market – and then suddenly, when they worked hard to get the feature in, it turns out that it is not a focus (anymore?) of sales and marketing. Or, they have made a quick and dirty implementation under pressure to capture a commercial opportunity and then suddenly sales and marketing starts marketing the feature on a scale they were not ready for. Apparently a more crucial conversation needs to take place (about the big picture) before delving into the details of each specific project.

When commercial units (e.g. sales and marketing) and development or delivery units (e.g. product development and service delivery) in an organization are not aligned, many things go wrong. Commercial efforts are made to market a product/service at a scale that the (development and delivery) organization is not ready for, development efforts are made without the proportional commercial support to market it. In the end all parties that are involved (and ultimately the customer) are disappointed and frustrated as the value that is created is not proportional to the investment that was made.

(note: I will talk about “product” as a synonym to “product/service”).

Organizations achieve alignment by linear top-down mechanisms (strategic performance management, business modeling, business cases) or iterative bottom-up mechanisms (e.g. iterative customer development). While each of these mechanisms are valuable, in isolation they give only a partial or fragmented understanding that may actually hinder alignment more than it helps. To explain this, we will need to look at the adaptive cycle metaphor as it is applied to products and services.

Adaptive cycleThe adaptive cycle consists of a front loop and a back loop. In the front loop of the adaptive cycle (exploitation to conservation, indicated in red in the figure below), an opportunity is captured and developed into a mature product within a mature market. To stay ahead of competitive pressure, the organization is continuously seeking to maximize value in the front loop.

Value maximization in the adaptive cycle

As the product and market jointly mature (in a co-evolutionary manner) product and market become very much interwoven and interconnected. Value maximization and increasing connectedness between product and market may push the product in a critical state. As the market matures, the product can become commoditized and competition may shift towards price competition. The organization may end up in the critical region where it overshoots it’s customer needs and becomes vulnerable to disruptive innovations (Ref. Clayton Christensen on Disruptive innovation). As the product grows it may become harder and harder to adapt to new needs and opportunities and ultimately the product and supporting organization may become atrophied.

Value renewal in the adaptive cycle

At the critical point the product may enter the backloop of the adaptive cycle (from release to reorganization, marked in blue in the figure above). Resources that are associated with the product are released and the organization seeks to reorganize the released resources to renew the product. It may seek to re-purpose the product to capture value from it in a novel way. Upon success, the product enters a new cycle to create new value. Upon failure, value is lost.

Cumulative success versus Cascading failure

Using the adaptive cycle metaphor we take a broader view than the usual S-curve. It is exactly this broader view that is of interest to us. In practice products may go many times through the adaptive cycle at different levels of scale (product-market, product capability-market segment, feature-user group). From a value creation perspective the front loop and the back loop of the product cycle are obviously very different.

In the front loop many reference points exist to understand value. The market is known and risks can be assessed. At best quantitative data is available, at least a good qualitative understanding by experts can be expected (an archetypical example of value assessment in this domain is the Alessi formula that is used by the Alessi company to assess the expected revenues of their design products; if you haven’t heard of it, just google it). The organization may need to invest to develop the necessary resources but investments can be justified based on the understanding of the value that can be expected. This is well know territory.

In the back loop, value is uncertain. The main question is how to re-purpose available resources so that novel value can be extracted. Quantitative data and qualitative understanding is limited. Rather than assessing value, the organization may seek to assess the impact it is making (e.g. impact on early adopters and thought leaders).

To understand value, organizations first, and foremost, need to understand where in the adaptive cycle they are operating. For a specific product – market combination the organization may be operating in the front loop; i.e. the market is an established market for standard usage of the product. For other product – market combinations, the organization may be operating in the back loop; e.g. the organization may be trying to enter a new market by using its existing product in a new way or by novel extensions to the product.

Failure to differentiate between operating in the front loop and operating in the back loop, leads to the typical mismatched expectations as indicated in the introductory story. As most mature organizations are operating in both modes at the same time, an explicit understanding of where each existing or targeted product – market combination is positioned is a prerequisite to any discussion about value.

Practically, the framework to distinguish between different product – market combinations needs to take into account 2 dimensions. The first dimension is value uncertainty – i.e. are we operating in the front or in the back loop? This is indicated as run-the-business versus change-the-business in the figure below. The second dimension is determined by the way we can interact with the market. Is it possible to co-operate for example with lead customers, early adaptors in an iterative way? Or is the interaction with the market mainly linear/transactional (first develop then market).

Domains of value creation

Taking into account the above mentioned dimensions, we get a Cynefin like framework with the following domains:

  • Standard: product/service as it is delivered routinely in the market or market segments where the organization routinely operates; value is created by enhancing the product/service according to evolving needs of customers
  • Extension: extending the product/service in adjacent markets (e.g. extending into higher ends of the market)
  • Emergent: using existing product/service or product components (in fact all available resources) in a way that extracts value in a new way; opportunities present themselves (or can be created) to gain hands-on experience with this new way of extracting value from the product/service; for example by means of lead customers and early adaptors
  • Sensitive: product/service-market combination that has arrived at the critical point where future value becomes highly uncertain because of changes in the market and the large and uncertain cost that is required to cope with these changes; different conflicting views exist about how to retain or re-capture value

Understanding value

Story: Wim has organized several contextualization workshops at different levels in the organization. The outcome of the workshops is a shared understanding about the positioning of the existing and future product-market combinations in the adaptive cycle. This shared understanding is documented as four domains that represent different levels of commitment of the sales and marketing unit as well as the product management and development units. In the run-the-business domain, a clear relationship is established between sales and marketing targets (in terms of revenue and market share) and product development targets (in terms of product capabilities). In the change-the-business domain the different units are aligned around the opportunities that they want to explore (e.g. domains in which to actively solicit and work with lead customers) and the strategic investments/riks the company is willing to take (market and product capabilities in which to pro-actively invest).

Posted in adaptive cycle, cynefin, value | Tagged , , , , , | 2 Comments

Cynefin, Panarchy, PDCA, OODA and value creation curves

The last couple of years I have been making use of Cynefin to make sense of complexity in project organizations. Cynefin has helped me to make sense of how projects differ and how to cope with these differences.

More recently I discovered the Panarchy model. Just like the Cynefin model the Panarchy model helps to make sense of complex systems. Specifically, it helps to make sense of the dynamics of evolving hierarchical systems with multiple interrelated elements. The panarchy model originated as a framework for understanding resilience in social-ecological systems. I think it may also have a great potential as a sens-making framework in the context of project organizations (that clearly fit the description of “evolving hierarchical systems with multiple interrelated elements”).

Adaptive cycleThe Panarchy model suggests that systems follows a four-phase adaptive cycle of (1) “exploitation” (r); (2) “conservation” (K); (3) “release” (Ω); and (4) “reorganization” (α). Quoting the Resilience Alliance: “The adaptive cycle exhibits two major phases (or transitions). The first, often referred to as the foreloop, from r to K, is the slow, incremental phase of growth and accumulation. The second, referred to as the backloop, from Omega to Alpha, is the rapid phase of reorganization leading to renewal.”

The metaphor of the adaptive cycle helps to make sense of the evolution of practice in organizations as depicted in the figure below. Similarly it can help to make sense of the evolution of the (hierarchical) systems (with many interrelated elements) that we are building.

Adaptive cycle and the evolution of practice

Equally important, the adaptive cycle can help to make sense of the mechanisms that we use to improve practice. I have seen people use and misuse the concepts of PDCA (Plan-Do-Check-Act) and OODA (Observe-Orient-Decide-Act). Using the adaptive cycle metaphor we can clearly situate both cycles.

Adaptive cycle, PDCA and OODA

Ecological and social-ecological systems form nested sets of adaptive cycles. The larger, slower cycles generally constrain the smaller, faster ones and maintain system integrity. From the Resillience Allience: “The fast levels invent, experiment and test; the slower levels stabilize and conserve accumulated memory of past successful, surviving experiments. The whole panarchy is both creative and conserving. The interactions between cycles in a panarchy combines learning with continuity.

Nested cycles

Also within project organizations we observe nested cycles. We can see organization-wide practice development at a longer time-scale (multiple years) and we can see practice development at the team level at shorter time-scales (weeks and months). We can see product evolution at the time-scale of the product life-cycle and we can see product evolution at the time-scale and scope of individual features.

The metaphor of nested adaptive cycles can help to make sense of the interactions between these different levels.

Shorter adaptive loops (of teams and features) can reinforce the longer adaptive cycle (of the whole organization and the product). The effect of these reinforcing loops on the value curve is reminiscent of the so familiar J-curves and S-curves.

Effect of reinforcing loops

Similarly, shorter adaptive loops can weaken the longer adaptive cycle. The system risks to go into a state of cascading failure.

Cascading failure

I am sure I have only scratched the surface here. I decided to put this post out anyhow to get early feedback. So, all input and feedback welcome! I will update the post to improve it.

Posted in adaptive cycle, complexity, cynefin, panarchy | 8 Comments

Manage the project end-to-end life-cycle with Kanban

Title: Manage the project end-to-end  life-cycle with Kanban (previously was “Accelerate the project flow with Kanban”)

Catalogue: Lean Adaptive Management – Addressing project management challenges 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

Focus on delivery

Story: Joe has recently been assigned a project in the business area that he is an expert in. He works for an international company. The project life-cycle that he needs to comply to, states that a user requirements specification (URS) is required before project development can start. So he has worked very hard to produce this URS. Now that he is in the process of seeking approval of the URS, he encounters a lot of resistance. The IT manager claims that he does not understand the URS; other stakeholders are not eager to give approval. According to compliance rules the project cannot start. In practice however – because of the pressure to deliver – IT has already started on the functional specifications. With all the discussion going on about this, somehow everybody is losing sight of the ones that matter most for this project … the users that later on will have to operate the system. Joe talks with his colleagues about the situation. It seems that many have similar experiences. It seems that the harder pressed they are to start the project the longer it takes to finish it.

Every project has a life-cycle. In many project organizations the project life-cycle has a formal character. In such cases, projects need to comply with it or tailor it to the project’s specific needs. In other project organizations, there seems to be a de-facto life-cycle, be it linear or iterative.

In theory, the life-cycle is there to prevent mistakes that will cost dearly later on in the project. In the linear life-cycle, we have stage-gates to prevent that we take short-cuts and ensure the quality of early life-cycle stage deliverables. In the iterative life-cycle, we have iterations because we want to avoid that big developments are done on unvalidated assumptions (assuming that these assumptions can only be validated by means of a working product). In theory, the life-cycle is there to ensure that value is delivered to the customer and users.

In practice, things turn out differently. Excellent delivery alone does not make success. In many project organizations, the project life-cycle starts when many important decision have already been taken. In many cases, the whole process of value discovery (understanding what value to deliver), is not covered in the life-cycle. Or, it is covered with much less detail and understanding. Generally, we tend to sub-optimize by overly focussing on the delivery side and not sufficiently involving upstream and downstream stakeholders (and ultimately the customers and users). It rarely happens that, the whole workflow is covered end-to-end, from idea to implementation. This applies to linear/waterfall life-cycles as well as to iterative/agile life-cycles.

From idea to implementation

But there is an even bigger issue. It has to do with  the tendency to think in one-size-fits-all solutions. For those that apply a linear life-cycle, all project must follow a linear life cycle – we need to think things through before we start. For those that think in iterations, all project must be iterative – focussing on delivery and feedback, here and now. In the ideal world, both types of life-cycles can work on their own. In practice a lot of energy is wasted in window dressing and using the wrong approach for the wrong situation.

It is no coincidence (in my opinion) that those involved in value delivery (developers, engineers, testers, etc.) are more inclined towards an iterative life-cycle and those that are involved in value discovery (business analysts, product managers, product marketing, etc.) are more inclined towards a linear life-cycle. The reason is the different time perspective of long-term value discovery versus short term value delivery. In practice this turns out to be a serious communication bottleneck. How many organizations have you encountered where there is a huge backlog of items to be developed – to the frustration of both the business and the development team -, but that development is continuously working on the basis of ill defined requirements because no one has the time or intention to turn these ill defined backlog items into well prepared work items? Project organizations need to be able to combine the long term with the short term and the life-cycles that are associated with it.

A chain is as strong as its weakest link. Project organizations need to manage the flow of work from end-to-end; from idea to implementation. The project life-cycle must include both value discovery as well as value delivery activities. The work that is involved with value discovery must be synchronized with the work that is involved with value delivery. And we need to combine value discovery and value delivery into both linear and iterative workflows.

End-to-end flow

Practically, we can set up Kanban boards for both value discovery and value delivery. The focus of the value delivery Kanban board is on managing the work in progress, the lead and cycle-times and helping the delivery team to self-organze. The focus of the discovery Kanban is on stimulating the engagement of upstream and downstream stakeholders (and users and customers), gaining an understanding of the priority of the most valuable work, and ensuring that all delivery work is well prepared. In the end the discovery Kanban must produce requirements with a clear value and priority in its output queue. Both types of Kanban boards are linked through a pull system. Delivery teams pull work from the discovery Kanban thereby signalling to the discovery teams that more work needs to be prepared in terms of e.g. requirements (but not to much of course).

The end-to-end Kanban as described in the previous paragraph is sufficient to manage the flow of routine work in a project or project organization. This includes maintenance tasks, standard services, routine performance improvements, routine enhancements, etc. The type of work where all requirements can be made clear upfront, the business case is straightforward because only one stakeholder is involved, the work can be executed by an independent team and there are no exceptional technical challenges. It all fits well in the current functional, technical, and business architecture. Work can flow linearly from discovery to delivery.

Linear flow

Not all projects are routine, of course. Sometimes more complicated work needs to be tackled: work where not all requirements can be made clear upfront, the business case is complicated because different stakeholders are involved, different teams are involved, and different experts need to be involved to clarify the business case and to help tackle technical complexities. Work can not simply flow linearly from discovery to delivery. The risk mandates iteration between value discovery and value delivery (iterative flow).

Iterative flow

Complicated projects start out in the same way as routine projects in the discovery Kanban. They are a combination of individual ideas that turn out to be too complicated to be delivered in one go. For complicated projects both the life-cycle of the project as a whole needs to be managed as well as that of individual work items. Work is managed on different levels: at the portfolio level the flow of projects is managed, at the individual project level the flow of project work items is managed.

Managing the end-to-end flow with Kanban

Story: Joe has set up a Kanban board for discovery. This Kanban board visualizes the flow of ideas, concepts and requirements. The different columns of the discovery Kanban represent different steps in the engagement with users and stakeholders. There is a cadence with which ideas are turned into concepts and concepts are turned into requirements. He has set up trigger points to ensure that at all times enough requirements are prepared to go into development (but not to much). As a result, Joe anticipates the pull of development but does not anticipate to much. At organizational level there are two levels of Kanban boards now: the portfolio level Kanban board in which ideas are collected, concept are prepared, and projects are qualified (routine or complicated), and the project level Kanban boards in which ideas, concept and requirements are processed for individual projects.

Posted in Uncategorized | Tagged , , , , | 3 Comments

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