The term “Lean” means many things to many people. Shakespeare buffs will think of Cassius in Julius Caesar and his “lean and hungry look”. Fashionistas will probably have a picture of an anorexic supermodel in mind. But Project Management Professionals (PMPs)^® and indeed anyone who works in industry will think of lean manufacturing.

On this page:

• The Foundations of Lean
• 1. Eliminate Waste
• 2. Amplify Learning
• 3. Decide as Late as Possible
• 4. Deliver as Fast as Possible
• 5. Empower the Team
• 6. Build Integrity In
• 7. See the Whole

The Foundations of Lean

Lean Manufacturing is the term used to describe what began as the Toyota Production System. Thanks to Toyota, the world’s Japanese vocabulary has expanded well beyond konichiwa and sayonara. Terms like kaisen and kanban are now common currency and we even hear the words muri, mura and muda from time to time. Lean manufacturing, lean supply chain management and lean product development are all part of the Toyota system.

Lean has attracted the attention of software houses who want to improve their product development; there is a lot to learn from how Toyota designs cars. However, it is important not to attempt to adopt practices found in different disciplines – it rarely works. However, if you distil the underlying principles from the specific practices, it is possible to build new practices suitable for the new application domain. Although a knowledge of lean will not help you on the road to PMP^® certification, it could help your organization improve the way it does business.

It is generally recognized today that there are seven lean principles and this article provides a brief overview:

1. Eliminate waste

Before you can eliminate waste (or muda in Japanese) you need identify it. The sort of waste many people think of when this principle is introduced is the offcuts left behind when a tailor or dressmaker lays a pattern over materials. A bit of planning or even a slight change in the pattern can reduce the size of the offcuts significantly, important if you are mass producing a particular type of garment.

However, waste has many guises. Movement is waste. Walking from your desk to the printer is waste, as is walking from the printer to another table to access the communal stapler. These walks are not productive.

Inventory is waste. A process might include a very expensive machine and the company decides to work this device 24 hours a day to maximize its investment. However, the result of this policy is a stockpile of output that must wait for the slower processes downstream.

2. Amplify learning

W. Edwards Demming developed a feedback loop called Plan Do Check Act. Essentially you decide on a course of action, apply it and then see what the effects of the action are. Based on this feedback, you can adjust the change for better results. The principle is to learn from studying the consequences of an action.

If you are familiar with agile software development practices (or adaptive life-cycles may be a more familiar term from your PMP^® training), you will see how their regular iterations (or sprints) provide this feedback. The developers present their work at the end of every iteration and modify their next tasks to take account of the feedback. A similar effect to amplify learning through feedback occurs with test driven development. By writing tests before the code, the developer can check how effective new code is straightaway.

While this can be frustrating for project managers trying to keep to a schedule, the enhanced knowledge provided through feedback ensures better understanding of what the customer actually wants.

3. Decide as late as possible

While preparing for the PMP^® exam, you met many documents that included assumptions and constraints. Unfortunately, many design decisions are based on assumptions, assumptions that often prove to be invalid. The lean approach is to focus on constraints and to clarify what the end product has to do. For instance, a car designer rarely starts with a clean sheet of paper. S/he will be presented with a series of dimensions outlining the chassis, the crash structure, the suspension and the drivetrain. Whatever shape s/he comes up with must fit around the other sub-systems. Similarly, there are statutory regulations dictating how high the lights must be and how the vehicle must reduce pedestrian injury.

Only when all the constraints have been tied down can the designer complete the styling work. However they do not sit idly by. Various styling options are sketched and refined, as the constraints become more concrete. While building up the set of constraints and adapting the designs as they emerge seems wasteful, it is a great deal more efficient than committing to a design too early and having to rework it to fit around the mechanicals. Harris Mann’s Austin Allegro is an example of a design that was distorted by having to accommodate a much higher engine than assumed.

4. Deliver as fast as possible

Traditional software development spends a great deal of time developing artefacts that non-technical end customers simply do not understand. The only thing a non-technical customer relates to is working software. So, to get the benefits of the customer’s feedback, we need to present working software as quickly as possible.

Project management professionals (PMPs^®) will be delighted to learn that this does not mean total anarchy, with software being lashed together without considering quality. Instead the idea is to deliver a sub-set of the required functionality and refine this based on the customer’s feedback.

If there are several possible approaches, develop examples of these approaches concurrently. This set-based methodology allows the customer to critique all options and provide useful indications of which direction the product should go. Often the final solution is an amalgam of the different options.

5. Empower the team

In the traditional command and control workplace, people are regarded as resources and direction is provided by management. Those of you with PMP^® certification will be reminded of Douglas McGregor’s Theory X. The lean philosophy is to have the people who best understand the work (those who do it) drive the process. It also insists that the workers understand the customer and the big picture.

It is widely accepted now that it is the work itself that is the primary motivator – recall Theory Y and Frederick Herzberg’s Hygiene factors from your PMP^® exam days. Having an appreciation of how their work contributes to the bottom line helps the lean team to stay focused on providing customer satisfaction.

Empowering the team leads to a better working environment and better results for the customers.

6. Build integrity in

Software tends to obey the second law of thermodynamics – entropy increases with time. As more and more functionality is added, the architecture, or integrity, of the product becomes increasingly distorted. Eventually, the code base becomes so cumbersome that it has to be abandoned and a new product developed.

The Extreme Programming practice of refactoring helps to maintain integrity. What happens is that the architecture where a new feature needs to go is assessed and re-designed if necessary. In other words, it is not acceptable to kludge some new functionality together and to destroy the integrity and maintainability of the code.

Refactoring is an example of kanban (just-in-time) architecture. The traditional software approach is for architecture design to be a one-off activity. So architects tend to over-engineer the solution in order to cope with any conceivable future requirements. This is wasteful: We are solving problems we do not yet have. It is also wishful thinking. Sooner or later a feature will require a different infrastructure, or a new developer will join the team and, not being familiar with the original architectural philosophy, will compromise the architecture.

By considering the architectural integrity before each addition, we can evolve the architecture to meet our needs, not our assumed needs. We also are maintaining the integrity of our product as we develop it.

7. See the whole

In the Project Scope Management knowledge area that we PMPs^® know and love, the Work Breakdown Structure is a vital tool. However, breaking down the work and keeping our people in silos, makes interfacing between the components difficult.

Each developer needs to see the bigger picture and the work needs to be organized so that interface issues can be identified and resolved more quickly. The agile approach of creating multi-disciplined teams is one way of doing this. Another is to develop closer links with your sub-contractors. Many car component suppliers have factories built as adjuncts to a manufacturer’s assembly line. Thus the sub-contractors can assemble their components on-site and slot entire sub-systems into the vehicles as they pass by their window onto the assembly line.

Another agile concept, that of continuous integration, also helps: Build the whole system every night; run the entire test suit automatically every night and stop work next morning if any problems are seen and fix them straightaway.

The seven lean principles all inter-relate and can be summarized by the slogan: “Think big, act small, fail fast; learn rapidly”. For PMPs^® being asked for faster turnarounds, agile and lean thinking can produce tremendous results.

Sayonara!