Lean in Practice for Projects

Lean in practice means self-organization with visual management and jidoka. When you’re more organized, it’s more likely that your work will have greater value.

In a previous post I defined lean as a concept for creating self-organization. This means visual management and a “take-things-as-they-come” attitude (jidoka). When a system becomes more organized, you’ll be more likely to see valuable work being created.

Lean In Practice – Visual Management and Jidoka

Visual management and “take things as they come” (jidoka) are two principles. A principle is something that will be achieved. A method tells us how to achieve a principle. Many descriptions of lean are based on methods and not the fundamental principles and this can lead to confusion.
In production, workcells are defined by the flow of material. The workcells can be linked together with a method called Kanban. When the different parts become more linked to each other, the system as a whole becomes more organized. Here is a short clip (1m20s) that demonstrates how Kanban works in production.

Methods are very valuable tools but methods that work well in one context might not work at all in a different one. For example, production methods can seldom be transferred to strategy and development, since there are no recurring repetitive flows. This is why we use other methods in strategy and development that link together actors and allow them to be more self-organized. For example, when working on projects, daily stand-up meetings in front of a Pulse board may be used for visual management.

Lean In Action – Pulse Methods

activity-window-postits

In the picture above you can see an activity window on a Pulse board. The window is divided into three parts: to do, in progress and done. The project group meets every day and discusses what they will work on based on what is on the board. This way of working is called pull. With pull, a demand for results is created in the same way Kanban is used for production. In classic project management, a plan which describes who and what should be done at what time is needed. To work based on such a plan is called push. The problem with the push principle is that we can’t predict the future. Plans that go far into the future have a high level of insecurity and lead to interference and wastefulness. Management and staff spend their days putting out fires. Pull only plans for a few hours at a time, which leads to less interruptions.

Push is also an example of how an exterior actor prevents self-organization. This doesn’t mean that planning is unnecessary nor impossible – only detailed plans are impossible. Comprehensive planning is possible as long as you are aware that there will always be faults in these plans. Comprehensive plans are necessary in order to know what should be on the To Do list. With Scrum, a prioritizing backlog is used. With Pulse we work with a comprehensive synchronization plan. However, management of daily work isn’t based off of this plan. Instead, it’s based off of the current needs that are visualized on the Pulse board that’s used during Pulse meetings.

Yellow and Red Post-Its

Planning determines which yellow post-its will be used in the activity window. The red post-it illustrates a way to handle unexpected problems that come up, jidoka. These problems must be handled quickly and efficiently.

When using lean, oftentimes the project members themselves plan and manage their work. They do this through putting up post-its in the activity window and through moving the notes on the board as the work progresses. The appearance of the board tells the group about its current needs and what they have to do in order to move the project forward. By moving the post-its on the board, it’s possible to see lean in action.

Unbalanced Workloads

Workloads within strategy and development are always uneven and need to be balanced. In order to handle this issue, the activities posted in the To Do section are not assigned to any single individual. Matchmaking between individual and task takes place at the Pulse meeting. Distribution is done by the individuals themselves in the form of taking notes. The role of the project leader is to make sure that no one is overloaded and this can be done by making sure that no one takes more than 1-3 post-its.

Lean In Action Depends on the Context

To summarize, lean in practice can look different depending on the context yet the underlying principles are always the same. When it comes to lean for strategy and development we have defined what we see as the foundation of lean in product development.

Little’s Law

Little’s law states that  there is a connection between the number of occurrences in a system (P), the throughput of the system (T), and the average time an occurrence spends in the system (L).

P=T*L

Lead times are important within product development. These can be calculated by using the formula above.

L=P/T

Average lead time = number of current projects / throughput of projects per year

Little’s Law and Projects

If you currently have ten ongoing projects and finish five projects per year the average lead time is two years.

L = P/T = 10/5 = 2 years

If you want to cut your lead times in half then you can cut the number of current projects. In the above example, the number of projects would be cut to five.

L = P/T = 5/5 = 1 year

By putting a limit on the amount of projects it’s possible to have more control over the average lead times.

Limiting the amount of projects is possible in product development where the projects are investments in new products that will allow the company to grow. If the projects are delivery projects that are begun in order to adapt a client’s product then this degree of freedom might not always exist. In these cases it’s necessary to increase throughput by hiring consultants.

But maybe it’s possible to increase throughput by increasing the efficiency of the operation? In order to find if it’s possible you can make a rough estimation by calculating the theoretical throughput. Add the currently available resources’ man hours in a year (be sure to remove time needed for other things beside projects, such as training, illness, etc.) and divide it by the average project lead time (make sure it’s effective time and not calendar or waiting time). A large difference between the theoretical and the actual value of the throughput will show if there is room to increase efficiency. However, be careful when reaching conclusions. The allocated time for a project usually heavily diverges from the actual time it takes to complete it according to classic project planning methods.

Little’s Law and Work

Since development activities does more things than work using projects it’s necessary to find solutions so that work can be queued and begun according to Little’s Law. All incoming work must be able to be to be queued and given access to the system which has enough capacity to handle it. We differentiate between projects and tasks and have queuing systems for both types.

Visual Management

Visuell styrning sänker osäkerheten.A lot of people who have worked with projects have experienced the same thing: downtime. You have to wait for people to get back to you, wait for results and wait for decisions to be made. On top of that other actors are waiting for you to finish your task that you can’t finish because you’re waiting for something or someone.

Forecasts are made to coordinate work in a businesses and projects. These forecasts tend to be wrong, which has led to the acquisition of more advanced, and expensive, forecasting tools, often in the form of some sort of IT solution. However, the forecasts are almost always wrong and thus we wait.

When you make detailed plans you make a future forecast. It’s just as easy or hard to forecast what will happen in four weeks within a project as it is to forecast the weather at the same time. In practice it’s impossible; the same laws that govern the weather apply to an organization.

However, there is an alternative to forecasting: visual management (also referred to as pull, lean or kanban).

Visual Management

Visual management was invented within production to solve the problems of wait time for materials due to errors in forecasts. When using outdated methods, if production cell A produces materials that are used by B a forecast is made of this use and A is allowed to produce according to the forecast. When there are many active production cells complex forecasts are created. In practice it’s impossible to make these kind of forecasts (see the book Chaos for an explanation as to why this is so). The forecast will lead to a lot of disruptions which forces management and workers to constantly run around, putting out fires. All this extra work is called waste.
On the other hand, visual management is based on how A can see by himself/herself how much material is used by B and produce more as needed (and not more). One example of this using boxes is when the material in one box is used, B sends the empty box to A to be refilled. Often a so-called kanban is used, so that when the material is down to a certain level B sends a kanban to A who produces the required materials.

Visual Management and Pulse

Pulse-activity-window

Visual management within strategy and development follows the same principles as production. A job’s current status is made visible using a whiteboard (a Pulse board) so that A and B can see the current situation. The status on the board tells A and B what they need to do in order for work to progress without wait times. The meeting where visual management is used is called a Pulse meeting. These Pulse meetings form a network and we refer to this as an agile network organization.

Workload Limits

A good system for visual management also needs to set limits for how much work can be done concurrently. The aim of setting such limits to keep the operation from overloading in order to keep the lead times short. Appropriate workload limits can be calculated using Little’s Law.

Leveling Workflow

Leveling workflow means that a limit is set for the number of tasks being done concurrently and that everyone helps each other out.

It’s common knowledge that traffic jams and congestion appear when there are more cars on a road than it’s been built for. In the same vein, having more work without the capacity to handle it leads to a kind of traffic jam within an operation. Overloading causes long lead times and a low throughput. It also causes disruptions that hinder cooperation, causes stress, puts quality at risk and generates waste. To avoid overloading a system it’s necessary to consider the current inflow and adjust it to the capacity and equalize the workflow over time and between individuals to avoid local overload. Equalizing the workflow is not trivial when there is a mix of different kinds of work to take care of. Even if measures are taken to balance the inflow there will still be tasks that are more time-consuming and may stop workflow in different areas.

Leveling Workflow – Helping Each Other Out

In the clip below an example of leveling  the workflow is demonstrated using a simulated product assembly that has been divided up into different steps. The clip features students from the  Technological University of Pereira, Colombia.

How did the equalization take place? The assemblers moved up along the assembly line every time they were a bit ahead. By doing this they could help assemblers’ upstreams and take over earlier stages when the product became more advanced and demanded more time. This way of working assumes that the workers know several stages of the production. They can enter the flow earlier and help out.

What relation does this have to projects? Projects usually involve collaboration between people from different professions. In product development there are designers, testers, purchasers, product technicians, people in logistics and marketers. In order to reach the goals of the project they need to collaborate. In practice some of the participants are always overloaded. Who they are varies over the project’s life cycle, which makes the total available resources in theory correct. The problem is that the resources aren’t used optimally when a large part of the project group is waiting for one member to finish their tasks. For the staff with extra time it’s often natural to start with the next stage of the project. The consequence of this is that interaction within the group is reduced which leads to an increase in waste.

Working Together Within a Project

So what should be done to equalize the workflow within a project? Firstly, don’t jump ahead and start working on stages later in the flow. Instead, make sure to finish the current stages. This means helping each other out. For example, if the designer is stuck on a design problem then other engineers and technicians in the project group should help out. This type of collaboration within a project assumes that a person is able to and ready to learn several stages/parts of the project. People need to let go of the idea of specialization and defined roles since it inhibits collaboration, learning and efficient use of resources.