Wednesday, 26 June 2013

Lean Project Management - It's all about value

What is lean?

The term "lean" was coined by three academics (Jones, Roos and Womack) in their book, The Machine
That Changed The World. Their book described the the Toyota Production System and the revolutionary impact that it had on the world's car manufacturing industry. Toyota wanted to compete on the world stage but lacked the resources to do so. Through necessity, Toyota rethought the manufacturing process and thereby gained a competitive advantage by drastically cutting the cost of production and significantly improving product quality.

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 Value

The 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.

Now compare a Rolex watch and a Sekonda watch. Which provides the better value? The Sekonda is considerably cheaper than the Rolex, so the Sekonda surely provides better value?

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 Stream

There 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.

Consider a big home refurbishment project. If you have ever seen the television programme Grand Designs, you'll get the picture. Typically, a couple decide to build their dream home by taking on a major refurbishment project of something like a Tudor barn. They vow to be in by Christmas. Two -thirds of the way through the programme, we cut to a snow covered building site, with the disconsolate couple, who have run out of money, still living in a temporary home, adjacent to the site.

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 Waste

The 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 Pull

Responding 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 Perfection

Pursuing 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.



However, if one opts for regular, incremental delivery, it is like running lots of mini-projects. Learning cycle times are shorter, it's the same overall challenge, with the same project team, working with the same customer.

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.

Summary

Lean thinking has a lot to teach us about projects by placing value at forefront of our thinking and aligning our work to deliver that value, based on customer pull. Think value not requirements and beware of approaches that build huge 'inventories' of requirements that are never used.

No comments: