Lean Project Management: Waste, Flow and Small Batches

Every project has a dirty secret, and it is called "90 percent done." Walk into almost any office and ask how the work is going. You will hear about the website that is almost ready, the report that just needs a final look, the contract that only waits for one signature and the new process that is basically finished. Add them up and you will find fourteen things that are 90 percent done and zero things that are done.

Nobody is lying. Nobody is lazy, either. The team is busy, perhaps busier than ever. But busy is not the same as finished, and customers do not pay for effort. They pay for the thing that arrives.

Lean project management is the habit of caring more about the arrival than the effort. It borrows from factories that learned this lesson decades ago and applies it to the kind of work most of us do: plans, quotes, launches, renovations, hiring, move-ins. You do not need a factory, a belt or a single piece of Japanese vocabulary to use it. You need a good eye and a little courage to start less so that you can finish more.

Where lean comes from, in two minutes

Lean grew out of the Toyota Production System, developed after the Second World War and associated above all with the engineer Taiichi Ohno. The Western world met it properly in 1990, when the book The Machine That Changed the World by James Womack, Daniel Jones and Daniel Roos described how Japanese carmakers were building cars with fewer hours, fewer defects and less inventory. Six years later, Womack and Jones put the ideas into five principles in Lean Thinking, and the word "lean" stuck.

Since then the ideas have traveled well beyond cars: to hospitals, software teams, offices, construction and kitchens. The reason is simple. Every organization has work moving through it, and every organization has places where that work stops, waits, gets redone or gets made for nobody. That is true of a car, a loan application and a kitchen remodel.

One caution before we go on. In some companies "lean" became a polite word for cutting people. That is not what the idea says, and it is not what this article is about. Lean as Toyota practiced it respects people and uses their eyes and brains to find problems. A project that is "lean" because it is understaffed is merely understaffed.

The five principles, translated for a project

Womack and Jones named five principles. Here they are in project language.

1. Specify value. Decide what the customer actually values, in their words. For a renovation it may be "the kitchen is usable before the family visit." For a website, "customers can book without calling." Not "all the features on the list."
2. Map the value stream. Draw every step from the request to the delivered result, including the waiting. This is the same map described in process improvement: map, measure, fix, and it usually produces a long silence followed by a shorter swear word.
3. Create flow. Remove the stops so that work moves steadily from step to step instead of in lurches and piles.
4. Establish pull. Start new work when there is room downstream and someone is ready for it, not because you can. This one is harder than it sounds in a business where every request feels urgent.
5. Seek perfection. Not "make it perfect," but "never stop removing the next piece of waste." It is the same spirit as kaizen, the habit of small and constant improvement.

If you remember only one thing from this list, make it the order. Value first, then the map, then flow. Most teams jump straight to "speeding up" and end up faster at making the wrong thing.

The eight wastes, as they show up in projects

The Toyota system named seven wastes, called muda in Japanese. Later practitioners in the West added an eighth: unused talent. Here is the full list, translated from the factory floor to your desk.

• Defects (rework). Anything done twice. The quote with the wrong price, the drawing that had to be redrawn, the report sent with last month's numbers. Each one costs the work itself, the time to find the error and the embarrassment, which is hard to invoice.
• Overproduction (work nobody asked for). Making more, or sooner, than the next step needs. The 40-page report when a one-page summary would be read. The feature no customer requested. The slide deck nobody opened.
• Waiting. Work sitting idle until someone answers, approves, signs or returns from vacation. In most projects this is the largest waste by a wide margin.
• Non-utilized talent. People doing work well below their skill, or ideas from the people who touch the work every day that never get heard. Your most experienced person retyping data is a small tragedy with a payroll line.
• Transportation (handoffs). Moving information or material from one place or person to another. Every handoff is a chance to lose context. A project that passes through six hands has six chances to forget the point.
• Inventory (work in progress). Everything started and not finished: open tasks, half-written proposals, unanswered requests. It looks like progress. It is money tied up in the form of paper.
• Motion (hunting). Looking for the file, the latest version, the person who knows, the password. Also switching between tasks, which costs more than it feels like.
• Extra processing (gold plating). More polish, more approvals or more steps than the customer needs. The third round of review on an internal memo is a classic.

Notice how many of those are invisible on a normal status report. A task shows as "in progress" whether it is being worked on or sitting in a drawer. That is why lean teams learned to look at the work itself and not only at the people.

Waiting is the villain, and the proof is arithmetic

If you take one number from your own project this week, take this: how many hours of real work does a typical item need, and how many days does it take to get through? A quote may need two hours of work and still take nine days. That is not nine days of effort. That is two hours of effort and nine days of waiting, and the customer feels all nine.

There is a tidy rule behind this, known as Little's law, which says that the average time an item spends in a system equals the number of items in it divided by the rate at which they finish. In plain words: if you have 20 jobs open and you finish 4 a week, the average job takes five weeks. Double the number open without finishing faster and you double the wait. The kanban guide shows how to use that in a team, and the theory of constraints article shows how to find the step that sets the pace.

This is why starting more work does not get you more done. It gets you the same amount done, later, with more switching in between. When someone asks you to "just get started" on a fifth project, the honest answer is not "I'm busy." It is "that will make the other four finish later, and here is by how much."

Flow: finish before you start

Flow means work moves without stopping. You get it with three habits.

Limit work in progress. Decide how many things may be open at once, per person or per team, and stick to it. When the limit is reached, you finish something before you start something. It feels slow for about a week and then feels like a sudden calm.

Make the work visible. A board with columns for waiting, doing and done is enough. The point is not the board. The point is that you can see at a glance where the pile is, so you stop guessing.

Remove blockers at once. Treat a blocked item like a stalled car on a highway. Everyone behind it is waiting, so fixing it today is worth more than starting something new today. Ask every morning: what is stuck, and who can unstick it?

For help finding the true limit of how much your team can take, see capacity planning and bottlenecks.

Small batches, with the arithmetic

A batch is how much work you do in one go before passing it on. Big batches feel efficient: do all the folding, then all the stuffing, then all the stamping. They are not. Here is a simple example with invented numbers.

Say you must prepare 50 packets, and each one passes through four steps: fold, fill, seal and label. Each step takes one minute per packet, and you have four people, one at each step.

• Big batch. The first person folds all 50 packets (50 minutes). Then the second fills all 50, and so on. The first finished packet appears at minute 151 and the last at minute 200.
• Small batches (one at a time). Each packet moves on as soon as it is folded. The first finished packet appears at minute 4 and the last at minute 53.

Same four people. Same speed. The work finishes almost four times sooner, and if the folding was done wrong, you find out at minute 2 and not at minute 150, when 49 more have been folded the same way.

That second point is the real prize. Small batches mean you learn early. In project terms:

• Launch five pages of the website and watch what visitors do before you build the other twenty.
• Show the client one room of the renovation plan before you draw the whole house.
• Send the first week's report to two readers and ask what they skip.
• Test a new process with one customer before you retrain the company.

Every slice should be a real, if small, piece of the whole thing that someone can use or react to. A slice that is only "step one of seven" and cannot be tried is not a small batch. It is a big batch in pieces.

The limits of lean, which are worth knowing

A method is only useful if you know where it stops.

Not everything that adds no value is waste. Lean practitioners separate value-adding work, pure waste and work that adds no value for the customer but cannot be dropped. Safety checks, legal approvals, permits, accounting and insurance are in that last group. Do not throw out the fire inspection because it does not appear in the brochure. Do make it faster and make sure it is done once.

One hundred percent busy is not a goal. A team with no slack has long queues and no room for the unexpected. The arithmetic of waiting gets worse as people get fully loaded, which is why a little free time is a feature of a healthy system and not a flaw.

Lean is not agile, kanban or Six Sigma. They overlap and borrow from one another. Lean is the family of ideas about value and waste. Kanban is one way to make work visible and limit it. Agile is a family of ways to deliver software and other work in small steps. If you want the comparison laid out, see methodologies compared and agile, waterfall or hybrid.

Culture matters more than tools. If people are punished for reporting a problem, they will hide it, and no board will help. Lean depends on people feeling safe to say "this is stuck" and "I made a mistake."

A worked example (illustrative)

Here is an invented small company to show how this looks in practice. All the numbers are made up for the example.

Maple Street Design is an eight-person design and build office. At any time it has 14 client projects "in progress." The owner feels that everyone is overloaded. A quick look at the work shows:

• The average project takes 9 weeks from signed contract to handover.
• Of those nine weeks, the team estimates 3 are real work and 6 are waiting: for client answers, for permits, for a supplier, for someone's review.
• On any day, each designer is switching between three or four projects.

The owner runs a one-week experiment with the team:

1. Look. They put all 14 projects on a wall with three columns (waiting on us, waiting on others, being worked on). Seven are waiting on someone else. Four are waiting on an internal review that only one person does.
2. Limit. They agree that no designer will have more than two active projects. The extra projects wait in a short list, in plain view.
3. Unblock. They add a rule that every item waiting on the client gets a call or a message by noon of the second day, not a hopeful email on the fifth.
4. Split. For two projects, instead of sending a full design package, they send room by room and ask for answers within two days.

Four weeks later (still invented), the office has eight projects active, the average time falls from nine weeks to six and a half, and the single reviewer is no longer the bottleneck because a second person was trained to share the review. Revenue did not change that month. The owner said the difference was that people stopped saying "I'm swamped" and started saying "this one is stuck on X." The numbers, not the mood, had become the topic.

The hall of fame of lean mistakes

• The Gantt cathedral. A beautiful, color-coded plan for work that has never been tried with a real customer.
• The pile that is called a pipeline. Sixty open requests, forty of them older than a month, all described as "in the pipeline."
• Lean by decree. A manager announces lean on Monday and cuts the budget on Tuesday. It is not lean. It is Tuesday.
• The speed demon. The team that hurries every step and creates a 30 percent rework rate, then wonders why the project is late.
• The inspector hero. One person catches all the mistakes at the end. When they go on vacation, quality goes with them. Build the check into each step instead.
• The sacred meeting. A weekly two-hour meeting nobody can justify and nobody dares cancel. Count the hours across the room and multiply by the hourly cost. Then ask whether the decision it supports could be made in 20 minutes.
• Tool worship. Buying a new project software to fix a habit problem.

Your one-week experiment

You do not need permission to run this on one project, and you do not need to call it lean.

1. Monday: look. List everything currently open on the project, with the date each item started. Mark which items are being worked on today and which are waiting, and for what.
2. Tuesday: pick the enemy. Rank the eight wastes below by how often they show up and how much they hurt. Circle the top one.
3. Wednesday: set a limit. Choose a maximum number of open items, and write it on the board. Anything above it waits.
4. Thursday: cut one batch. Choose one big deliverable and split it into two slices that someone can react to. Send the first slice.
5. Friday: measure. Record the days from start to finish for the item you delivered, and compare it with similar items from the past. Write down one thing you will keep and one you will change.

Then repeat for another week. Lean is not an event. It is a short loop you keep running.

Try the tool: rank your wastes

The tool below lists the eight wastes. Rate how often each shows up on your project and how much it hurts, from one to five, and it ranks them. The sample ratings are made up, so replace them with your own. Start with the top one, and only the top one.

Interactive tool

Rank the wastes on your project

Loading the tool…

What to do this week

• Count how many things are "in progress" on your busiest project and write the number where the team can see it.
• Pick one item that has been waiting more than a week and find out who can unstick it today.
• Choose a limit for open work and try it for five working days.
• Split one big deliverable into two slices and ask for feedback on the first.
• Read process improvement: map, measure, fix and put your own process on a wall, or follow the process teardown series to see one common process taken apart step by step.

If your projects keep piling up and you would like a second pair of eyes, that is the kind of work I do in operations consulting. You can also start with a conversation or browse the free templates in the toolkit.

The ideas here are general guidance based on well-known lean principles. The examples are invented, and the arithmetic is simplified to show the point. Check legal, safety and compliance requirements for your own work with a qualified professional.

Frequently asked questions

What is lean project management in simple words?

It is a way of running projects that focuses on delivering what the customer values and cutting out everything that only consumes time. You find the waste (rework, waiting, half-finished work, unneeded extras), keep work flowing, deliver in small pieces and keep improving in short loops.

Is lean the same as agile or kanban?

No, but they are relatives. Lean is the broad set of ideas about value, flow and waste. Kanban is a simple way to make work visible and limit how much is open. Agile is a family of ways to deliver work in small, adaptable steps. Teams often combine them.

Does lean mean cutting staff or working people harder?

It should not. Lean as it was developed treats waste as the enemy, not people, and it relies on the people doing the work to see problems and propose fixes. Cutting headcount without fixing the process just creates a slower process with fewer people.

Where do I start if my team is already overloaded?

Start by limiting work in progress. Count what is open, set a limit a little below the current number and finish items before starting new ones. It does not need extra time or money, and it usually makes the overload visible and then smaller.

Join the conversation

Did this help? A quick reaction tells me what to write next.

Useful Made me smile Go deeper on this

Be the first to react.

Comments

Loading comments…

Leave a comment

Name (optional) How many things are "90 percent done" on your desk right now? Post comment

No email and no sign-up. Every comment is reviewed before it appears. Please keep it respectful and leave links out.