What is lean?The term "lean" was coined by three academics (Jones, Roos and Womack) in their book, The Machine
Two of the authors, Womack and Jones, went on to write another book, entitled Lean Thinking, which argues that lean thinking can be applied to all types of processes and organisations. They articulated five inter-related 'principles of lean thinking':
I believe that these principles can be applied to projects, with a similarly radical impact on cost and on quality. In the following sections, I'll set out how I believe that these principles can be interpreted for projects but if you are in a hurry, there is one key point:
It's all about value!
Superior customer value is the raison d'être of lean thinking. It is about understanding and identifying what our customers value and only doing those activities needed to deliver that value. And then constantly striving to improve how we do that. For projects, it is not about requirements - it is about value. That's the major mind-shift.
1. Identify Customers and Specify ValueThe term “customer” comes naturally when thinking about car manufacturing. But it is not a term that one hears a lot in projects. It is more likely that people will be talk about the 'sponsor' and 'stakeholders'.
However, the language that we use to describe things is important. The mind works in concepts and words are effectively tags that give us a route to those concepts.
As Nobel laureate Daniel Kahneman (pictured right) tells us in his seminal book, Thinking Fast and Slow, an individual word prompts our minds to instantly fire off a vast range of subconscious associations.
The word 'customer' triggers associated concepts that include expectations of what is to be a ‘customer’, familiar to us from our daily lives. Stop for a moment and make a list of the characteristics that define a 'sponsor' or 'stakeholder'. Now do the same for ‘customer. It’s quite a contrast.
Or think about the word ‘student’. When I grew up, in England, going to university was free. We felt grateful to get there and treated the academic staff with great deference. Nowadays, a student in England has to pay £9,000 per year in fees. That’s a minimum of £29,000 for a degree, more than the cost of most cars. But despite paying so much, for a service, we still use the ‘student’ to describe those paying for the service. How might behavior change if they started to refer to themselves as customers? That’s exactly what a lot of business school students do and I can assure you it keeps the academic staff on their toes.
Having identified the customers, we need to determine what they see as value. Value can be defined as the ratio of benefit to resources consumed (usually money) to obtain the benefit. Thus:
value = benefit / resources consumed (usually money)
But the other key point is that:
value is in the eye of the beholder
Consider a wristwatch. Let's say the benefit is the ability to tell the time and the resource consumed is the money to pay for it.
The answer is that it depends on the perspective of the customer. Someone I know started a business as an independent recruitment consultant. He was very young and although he didn't have much money when he started, he bought a Rolex. For him, it wasn't a luxury purchase. It was a necessity: his benefit in the value equation was showing a visible symbol of success to prospective clients.
Value is in the eye of the beholder and from a project point of view, we need to understand and map the value that customers and other stakeholders will derive from the project. If we're smart, we'll also map the value they derive from the status quo, before we think about changing it.
Projects usually talk in terms of benefits and, if they are good projects, they will quantify those benefits. I believe, however, that thinking in terms of value, rather than just benefits, is more powerful because it encapsulates both cost and benefit into a single concept. And as the next principle points out, this can make a critical difference when mapping the value stream.
2. Identify and Map the Value StreamThere are two ways of looking at this principle from a project perspective. The obvious way is to identify the stages that the project needs to go through to deliver its value. These stages are pretty well defined in most industries. It is usually something like: feasibility, requirements, design, build, test, commission.
An alternative way of looking at the value stream, however, is to take the value defined by principle #1 and break it down into a stream of desirable value.
Alternatively, they could have collaborated with their builder to map the value stream. Having identified a functioning toilet as having particularly high value, they could then have asked for it to be delivered first.
This might be followed by a shower room, followed by a kitchen, then a bedroom and so on. The total value could have been delivered in chunks. The builder might argue that this approach would make the overall project more expensive. But they ran out of money anyway, because it was always going to be impossible to estimate the cost of such a novel project. Wouldn't it be better to have a four-bedroomed home with a roof, rather than an uninhabitable eight-bedroomed home without one?
Putting the toilet first illustrates why it is better to think about value rather than benefits. The highest value is not necessarily associated the item with the highest benefit or highest cost. It is a function of benefit, cost and schedule...and is in the eye of the beholder.
Note that taking this approach requires the customer and builder to think about solutions that allow for incremental delivery of value. You don't design a solid oak wardrobe for Ikea and then try to figure out how to flat pack it. Ikea furniture is designed to be flat packed. Delivering a value stream needs to be a design criteria.
There is another benefit of this incremental approach that I will talk about in principle #5
3. Create Flow by Eliminating WasteThe Standish Group have a database of over 70,000 IT projects. They report that 'only about 20% of features and functions specified ever get used'. That's clearly a lot of waste. Considerable effort is being spent writing, reviewing, designing, testing and implementing requirements that are never used.
The problem isn't restricted to IT projects. I have been involved in some large, well-funded corporate start-ups. And every time, the project team sets about creating processes and procedures, to be used by operational staff who are not scheduled to be recruited until quite some time in the future.
And every time, when the permanent recruits arrive, they bin the stuff done by the temporary project team and create what they really need, when they need it. Not only is the planning and execution of this sort of thing a waste, it impedes the flow of value by using up intellectual and emotional energy.
In projects, creating flow, by eliminating waste, is tightly coupled with the next principle: responding to customer pull.
4. Respond to Customer PullResponding to customer pull means taking an increment of value and identifying what needs to be done, and only what needs to be done, to deliver it.
Psychologists have found that looking back from a richly imagined future state engages more areas of the brain than planning forward, towards an outcome. This is one of the reasons why most successful sportsmen and women, spend a lot of time doing outcome-based visualisation, including the act of lifting the trophy.
Identifying an increment of value and then looking backwards, to identify what is needed (and only what is needed) to deliver it is a powerful tool for projects. It's also why a shared, richly-imagined, vision is such an important foundation stone for project success.
5. Pursue PerfectionPursuing perfection is about continuous improvement. This is difficult with projects because:
- The learning cycle has a long duration because similar situations don't repeat quickly.
- Each project tackles a different challenge.
- Each project tends to assemble a different team.
- Each project has different customers and stakeholders.
And each time value is delivered, we can evaluate:
- Cost and duration versus forecast.
- Value and quality versus expectation.
- The relationship between customer and supplier.
Regular delivery of value provides us with a the tools with which to pursue perfection, within a single project.