Lean Thinking Tools for Improving Your Portfolio Planning and Prioritization Process

We just started an IT Transformation for a new client that is looking to fundamentally change the way they deliver IT services and application development. As part of the transformation we are helping the organization improve their portfolio planning and prioritization process to provide greater transparency, flexibility and control (yes control and agile does go together). Whenever we work with clients in this area, the first step we take is help them break down their old mental model of portfolio management and take a fresh perspective. To do this we introduce four thinking tools to help them wrap their heads around the new concepts. The goal of the four thinking tools is to help organizations look at planning and prioritization as an economic bargaining system.

Thinking Tool 1: Three level planning approach controlled by cadences

The first tool is to stop looking at portfolio planning and prioritization as a one time annual budgeting process and instead move towards a frequent multi-level planning system for portfolio management. Each level of planning should have well-defined units of work, cadence, and a form of currency (more on that later). The specific goals of each level are:

Strategic Planning:

• Identify ideas to realize strategic business objectives
• Set allocation based on LOB / Program / Work Type
• Longer Cadence, example quarterly

Project Planning: 

• Idea analysis and project planning
• Define projects in terms of business valued features based on a high-level solution
• Medium Cadence, example monthly

Operational Planning:

• Project work intake with frequent work replenishment for solution delivery
• Dedicated intake channel for emergencies, small enhancements and bug fixes
• Short Cadence, example bi-weekly

Thinking Tool 2: Breaking projects into minimal releases and business valued features

Based on Thinking Tool 1, if the organization is able to establish more frequent strategic planning cycles (e.g. quarterly) than this encourages projects to be broken down into smaller chunks that can fit into those cycles. This allows IT to work more frequently with the business to understand what the high value features are and get to quick wins faster. At the same time this also provides greater transparency of progress into budget spent vs budget realized in terms of real value (i.e. a potentially shippable system).

Thinking Tool 3: Planning informed by capacity in terms of throughput to level demand

One of the challenges with traditional planning approaches is that capacity is not used to inform the planning process. To build an effective planning and prioritization process the organization needs to understand capacity in terms of throughput (how much value can I deliver within x amount of time) and level demand based on available capacity. What we often see broken with traditional processes is budget being the only input into the planning process and that is typically not the "bottleneck" or scare resource in the organization. Money is abundant, time is not which leads to the end of year madness many organizations fire fight their way through.

Thinking Tool 4: Establishing currency to represent scarce resources provides a mechanism to facilitate exchange of value to promote liquidity and flexibility

The final piece to the puzzle is establishing a common unit of currency based on scarcity. Instead of throwing money at the problem, the organization starts looking at their delivery capabilities as system of work that has real constraints (i.e. time). The unit of currency we alluded to earlier in Thinking Tool 3, is throughput which represents work/value in terms of time. The currency is then limited based on scarcity which is represented as work-in-progress (WIP) limit that controls the backlog and queues that work fits into.

By understanding these four thinking tools they provide an organization with the foundations for establishing a fast feedback portfolio system managed by multi-level planning with cadences, defining projects into smaller increments of value, balancing demand based on throughput, and planning and prioritizing based on a common unit of currency that represents scarcity.

In a later post, I'll share a set of planning and prioritization patterns we use to implement these concepts.

Using the Business Model Canvas in an IT Transformation

The Context
Our client is initiating an end to end transformation of both business processes and IT systems used to deliver services to its customers. The goal of this transformation is to enhance the ability of their IT Organization to execute on the delivery of new applications, changes to existing applications, and support/maintenance activities. The organization also requires enhanced capability to better execute on delivery strategy, governance, and standards. This transformation will enable our client to better meet the demands of its clients by increasing throughput and quality, while simultaneously reducing delivery lead time.

As part of our initial discussions with directors and managers we decided that the business model canvas can be effectively applied to describe the client’s current software and services delivery model. Based on insights from Directors and Managers, we filled up a 6 x 8ft canvas with sticky note insights.

What is the Business Model Canvas?

The business model canvas is a tool that helps you describe, design and visualize a business model. The canvas helps an organization describe how they intend to deliver value by focusing on 9 building blocks:

1. Customer Segments
2. Value Proposition
3. Channels
4. Customer Relationships
5. Revenue Streams
6. Key Resources
7. Key Activities
8. Key Partners
9. Cost Structure

It is not enough to look at the building blocks as a checklist – they are assembled in the canvas below to help visualize the relationship and interactions between them:

The building blocks focus on a set of key questions that help collaborators capture their insights and facts about the current or target model. These insights and facts are captured on sticky notes so that they are never permanently fixed to the canvas. We adapted the original canvas from the book, Business Model Generation, to suit our unique need.

If you want to learn more about this tool, you can purchase the book, Business Model Generation. There is a 72 page sampler of the book at http://bit.ly/jXCPHQ.

The Custom Canvas
The client environment is quite different from the examples and cases available in the book so we modified the building blocks to suit our particular needs. After several iterations we landed on the following building blocks:

These building blocks were used to create a 6 x 8 foot canvas on a wall in our war room. We had multiple stakeholders from the client team join our business model canvas workshops to capture their insights on some key questions to help us populate the canvas:

1. Who are your customers? Which customers use which services? How is demand communicated to your department? How does intake work?
2. What vendors do you currently work with- both internal and external to your organization? How do they contribute to delivering value?  How do you coordinate to deliver?
3. How do you measure performance? What does your performance look like for the various kinds of work that your department does?
4. What types of tools, processes, and accelerators do you leverage to add value? Which ones are you thinking of using in the future?
5. What do you believe are the major risks or issues that interfere with delivering business value? What counter measures have been attempted to solve these problems or mitigate these risks?

As we conducted the sessions, we started to identify 3 major types of insight. The sticky notes were tagged with a colour corresponding to the types below:

1. Pain Point (red) – something the client wants to change because it is not working well
2. Target State (blue) – something the client wants to have because it will help to deliver more value to the customer
3. No Change (green) – something that is working well and do not want to change

We not only used sticky notes, but also modeled using blank sheets of paper and affixed it to the canvas with painters tape. After the first wave of workshops, we communicated an open-door policy. Anyone can walk in and start adding things to the canvas with our help. Below is a photo of the results:

We ended up with a canvas that helped us get an understanding of the client’s delivery model, pain points, and things that are working well. We also started to look to the target state with many suggestions for positive change. This canvas is in a constant state of flux and changes daily capturing thoughts and facts as we learn and discover. Finally, right at the top of our canvas, we wrote the client’s vision on a sheet of paper to anchor the discussion overall.

You Can't Trust Your Workers Metrics Unless Your Workers Trust You

It's common to place a lot of faith in the power of what metrics can tell us. I've met more than one executive who romanticized about some kind of super dashboard that could pinpoint all the risks and issues, allowing them to base key decisions largely on the data they are seeing.

This could be a desirable target state, if you are doing something simple, like delivering pizzas.

In today's customer experience economy many of us are involved in something a little bit more complex. We are more likely to engage in tacit activities, activities that require analysis, learning, collaboration and on-the-fly synchronization. Chances are, we are engaged in knowledge work.

A profound truth that many fail to appreciate is that knowledge work is inherently variable. Each request for a service or product is always a little bit (or a lot) different from the last one. And you can't remove this variability from the equation. Doing so will remove the work of its value, the work will no longer be something new. Robots could do it.

This makes getting meaningful metrics somewhat problematic, comparing one unit of work to another will always require some creativity.

What this means is you can't measure knowledge work effectively unless your knowledge workers want you to.

Measuring knowledge work means measuring abstractions of the work your knowledge workers do. A trial and error exercise is required to come up with something meaningful. You need commitment to get to a stable performance baseline.

Even more so you'll need courage. Metrics for knowledge work are extremely easy to game, and being transparent about bad data is something very few organizations do well.

And it's not a one-time thing, the approach you take to measuring whatever it is you want to measure will always be little bit wrong. The context that knowledge work takes place in is always changing.


If your workers don't trust why these metrics are being used, you won't have accurate data. You won't have the insight required to know what to do with that data. And you will make bad decisions in the name of that data.

Metrics can be a good thing. But trust comes first.

Kanban 101

Kanban is a less disruptive path to a higher state of organizational maturity.

Kanban inspires a culture, where everyday staff, focus on incremental improvements. This type of culture ensures that an organization can make changes that are tolerable, both right-sized and at the right pace. Over time, organizational maturity grows, and with it, higher performing teams.

The incremental change approach is vastly different from a “Big Bang” approach. A Big Bang approach typically impacts performance to a level where the change initiative is at significant risk of failure. As performance drops significantly, several challenges arise: low employee morale, loss of trust among executive sponsors, or simply, the organization cuts their losses and resorts to the old way of doing things.

Limit the amount of work entering the system.

By limiting the amount of work that enters an organization’s delivery center (e.g. enterprise software delivery), the organization can focus on continuous improvement through its workflow among teams and value stream overall. A domino effect results:

1. Reduce Work In Progress (WIP) Limits – Lowering the level of work in progress (inventory) has a significant, positive impact on average completion time of individual work items
2. Reduce Task Switching – As an individual item is completed faster, the need for wasteful task switching between work items is reduced
3. Reduce Cycle Time – Lower average cycle time means shorter lead time for individual work items
4. Increase Feedback - Quick turnaround time also means that quality checks are done with a fresh concept”, and the opportunity for error decreases
5. Increase Quality - Increased feedback improves the quality of the final result
6. Increase Team Maturity - Increased Quality leads to an increase in overall team maturity and performance, quicker lead time results, teams are further able to lower the levels of work in progress

Kanban is an approach to visually represent a unit of value.

The Kanban Approach:

• Visualize the work – a visible display of moving work to completion becomes a powerful reward
• Pull work based on WIP limits – to create a predictable workflow
• Empower staff to improve processes – simple, visually represented measurements of progress become intrinsic motivators to do the right thing

How does it work?

• Management and staff have a common understanding
• Bottlenecks, issues, and defects are easy to spot
• Explicit mechanisms for root cause analysis and continual improvement
• Demand is limited, fostering focus, early delivery of value, and making bottlenecks obvious
• Defect correction focuses on the source of the defect, not just the defect itself

Work Policies continually evolve as the organization matures.

Organizations build policies and modify them as they are incrementally changed through improvement discussions. Teams may define policies at different levels of detail such as work policies (at the workflow level) or team policies that apply to the team as a whole. For example, a team policy is conducting a daily stand-up at 10AM every day. A workflow policy may define entry and exit criteria for a given phase in the workflow.

Kanban allows teams, managers, and the organizations as a whole to become better at measuring.

Kanban provides the tools to predict delivery time, reduce risk, and analyze problems using quantitative methods. Tools such as statistical process control charts, and cumulative flow diagrams will provide robust metrics managers yearn to discover.

If you would like to learn more, visit the links below:
Limited WIP Society - http://www.limitedwipsociety.org/
David J Anderson & Associates - http://agilemanagement.net/
NetObjectives - http://www.netobjectives.com/
Lean Software and Systems Conference - http://lssc12.leanssc.org/

Up Front Design Is Not Design

If we don't create a reusable design, we will pay down the road. If we don't properly anticipate requirements, we will incur rework. If we don't get the design right up front we are, for a lack of a better term, royally screwed.

If you disagree with the above, then feel free to stop reading, this post will contain nothing new for you.

If you are of the opinion that the design of any kind of information system is something that is done up front in one big batch, I urge you to keep reading.

Design is an act of pattern matching. You are scanning a range of solutions in an attempt to improve the experience of a particular context. 

Design involves equal parts analysis, building, and perhaps most important, testing. 

The key to good design is iterating. Iterating as fast as possible.

Good design involves searching, mixing, inventing, testing, testing, and more testing. 

Good design doesn't come from a better crystal ball, it comes from feedback. And being able to respond to that feedback.

The act of analyzing requirements, modeling a solution, and handing it to a development team isn't an act of design. 

Its an act of analysis. Its an act of direction. One that is rooted in assumption.

For this to be an act of design, you need to complete the entire cycle.

Not all problems require design to solve them. Maybe you are applying a cookie cutter solution to a commoditized problem. Maybe you just need coordination. 

But even complex coordination requires good design to pull off well.

You don't need take my word for it. 

You could pay attention to the growing bodies knowledge out there that are spreading the same message.

Design thinking, Service Design, Managing to Learn, LeanStartup, Radical Management, OODA, Gamification, and Systems Thinking seem to all touch on the same truths. 

Up front and design are the  antithesis of each other. Let's strike it from our vocabulary.