Lean Project Management

Choosing "your project" to use for the exercises in the rest of the course.

This video is discusses how to apply the first principle of Lean Thinking to projects and it's all about value

It highlights that the perception of value varies between individuals, groups and contexts. Value is in the eye of the beholder and the context within which it sits.

The video also highlights the importance of the language that we use to describe things. Terms such as "customer" or "value" trigger a complex, unseen network of associations in our minds that are called up to embody the concept. Thus, the word "customer" has a very different connotation to the more neutral sounding "Stakeholder".

Similarly, the term "value" encapsulates both cost and benefit in a single concept that our minds are used to dealing with.

Slides to help with the exercise: the list of types of value described in the video, plus a slide describing the exercise.

This video highlights the role that emotion plays when thinking about value.

Think about the big decisions you make in your life? The really big decisions:

• your life partner?
• where you live?
• your home?
• your car?

The bigger the decision, the more we are driven by emotional rather than rational needs. Think for a moment about the way that cars are advertised and sold.

But when it comes to projects, we assume that all of the customers and stakeholders behave rationally. We leave emotion is left at the door. But if we want to understand value, we need to understand emotion.

Product designers have understood this for many years. And indeed, first step in the design process created by Stanford University's Institute of Design is to empathise, as described in the attached PDF.

A slide that summarises the exercise from the previous video.

This is the absolute crux of Lean Project Management, so I urge you to have a genuine attempt at this exercise.

This this video discusses how to apply the second principle of Lean Thinking to projects and it's about the value stream.

For projects, there are two ways of thinking about "the value stream":

1. the sequence of project stages and activities, such as: requirements, design, test and implement
2. a sequence of usable business value that is delivered to customers, preferably regularly

The first can be worthwhile, to ensure that each stage is understood and genuinely adds value. However, this sequence is well-defined for most IT-based project suppliers, so I don't dwell on it in this video.

The second interpretation, however, causes us to look at projects in a different and very novel way. This is the key to a radically different approach to projects that recognises the impossibility of accurate estimation and the associated optimism bias that underlies it.

Instead we structure our projects to delivery regular chunks of usable business value. That is our value stream.

Notes:

The video clip, about the building project, is taken from the UK Chanel 4 programme "Grand Designs". You can see the full programme on the show's Youtube channel.

Sadly, the story told in this programme is similar to many others in the series. A family starts off with an ambitious plan to build their dream home. They have stretched their finances to do it and often target to be "be in by Christmas". Alas over optimism and novelty combine to create delay and escalate costs and there is a crisis about a third of the way through the programme.

But fear not, there is usually a happy ending and somehow the money is found and something stunning is created. And that was the case in this instance and, in fact, there is a follow-up programme that tells the full tale that you can watch here.

This video is discusses how to apply the third principle of Lean Thinking to projects and it's about flow and waste.

The video uses a simple example to explain what is meant by flow in manufacturing and how achieving flow helps to eliminate waste. It goes on to explain how this relates to software projects.

The essence is that if one stage of a project produces more stuff than the next stage can use, it sits there doing nothing. It has, however, cost money to produce and effectively ties up money.

That's particularly relevant when we consider the Standish Group finding that less a quarter of requirements ever get developed and only a fifth of features and functions developed ever get used.

Agile projects (see the video"Agile versus Waterfall, at the end of the course to explain the terms "Agile and "Waterfall") are not immune. Scrum implementations often run "sprints" as series of "waterfalls and are driven by prioritising items from a "product backlog".

I've shown Agile as a series of stages to illustrate a point but recognise that a really world-class agile implementation, especially those using Kanban (again see supplementary videos at the end of the course) will have a multi-function team, without a split into developments stages. This is, however, in my experience, relatively rare.

Notes:

The figures on wasted requirements and functions and features comes from Standish Chaos Manifesto 2013 which was attached to lecture 2 as a download.

The figures on value shortfall come from the McKinsey Insight Report: ""Delivering large-scale IT projects on time, on budget, and on value" which was also attached to lecture 2.

Summary slide for exercise from previous video

This video is discusses how to apply the fourth principle of Lean Thinking to projects which is about customer pull.

This fourth principle, of "pull", is tightly coupled with the previous principle of creating flow by eliminating waste. Indeed, a key way that we achieve flow and eliminate waste is by focusing on a specific chunk of value that is being "pulled" by customer demand.

In Lean Project Management we identify the value stream as regular chunks of value. We use the "pull" of a chunk of value do the work to deliver that value BUT ONLY THAT WORK NECESSARY TO DELIVER THAT CHUNK OF VALUE.

But there are two important clarifications that I'd like to make. First, delivering chunks of value still has to sit within the context of an overall architecture and design. There may well need to be work, early on, to design and build enabling infrastructure.

In our Grand Designs example, our first chunk of value is the toilet. To deliver that value, unless it is a temporary structure, we need to know where it goes within the overall design. And we are likely to have to create drainage and plumbing infrastructure to make it work. Similarly, we may well have to lay down the electrical infrastructure necessary, early on, to allow future chunks of value to be delivered.

But be watchful and , be really pedantic with your suppliers. Ensure that you only do the essential design and infrastructure. Don't be lured into doing all of it, because if you do, you can guarantee that you will waste a lot of time and money.

The second clarification is that I am not saying that a value stream has to be delivered sequentially, with nothing starting until the previous chunk of value is delivered. In most projects, it's possible to pursue some chunks in parallel. Indeed, if you are managing the people on the project directly, you may need to smooth demand, to keep the workforce reasonably level and not have to keep laying off and taking on workers.

But there is an important caveat on this. If your project is one in which human behaviour plays a major role, and most do, it often makes sense to pause and evaluate how a chunk of value works in practice before rushing to deliver the next chunk. That's why the next principle is so important. Deliver quickly, learn and adapt.

Slide summarising exercise from previous video

This video is discusses how to apply the fifth principle of Lean Thinking to projects which is about how to pursue perfection - constantly striving to improve the outcomes we achieve.

This is usually difficult to do with projects because the learning cycle time is usually long in two ways. First, on a project there is usually a long gap between doing something and seeing the outcome in practice. For example, the time between defining a requirement and it being used in practice. Secondly, the duration of projects is such that the opportunity to apply a lesson learned may not come along for many months or years.

However, if we deliver regular chunks of value, each delivery is an opportunity to evaluate, learn and adjust. And critically, we can evaluate not just how well we think we did the task but whether we got the value we expected. We can evaluate:

• whether we got the value we expected? if not why not and what can we do about it?
• how much the cost and time varied from the forecasts
• who well our relationship worked with suppliers and customers

Also, in contrast to attempts to apply lessons from one project to another, we can learn with the same team, on the same project, with the same suppliers and the same customer.

And, as I said in the notes for principle #4, if your project is one in which human behaviour plays a major role, and most do, it often makes sense to pause and evaluate how a chunk of value works in practice before rushing to deliver the next chunk.

This video discusses the importance of defining the project's problem, need or mission. It asks whether you are sure that your project solving the right problem?

It's amazing how many projects begin without really thinking through the core problem that needs to be solved.

In addition, as Apple's head of design, Sir Jonathan Ive, tells us in the video clip, the words that we use to describe the problem can determine the path that we go down. That's what is known as framing the problem. Different frames, will yield different results.

So the first challenge in starting any project is asking:

• Do we understand the core reason why we are doing this project?
• Is it the right reason?
• Have we described that problem in a way that leaves open the widest possible range of solutions?

But having asked those questions, we also have to acknowledge that frames will, necessarily, have some constraints that limit solutions.

So, for example, if our organisation's mission is to alleviate poverty, we have to narrow down individual projects to things that are practically achievable, such as harvesting rainwater, to provide safe drinking water. But we could also have made it simply about drinking water. It's a choice that is made knowingly and explicitly.

There is nothing wrong with having some key constraints, as long as they made explicit and the reasons for them are made clear to the project team. As we'll see later in the course, when discussing solutions, creative use of constraints can be a way of stimulating creativity. But at this stage, we prefer to have as few as possible and to frame the problem as widely as possible.

Slide summarising the exercise for defining the right problem.

This video discusses the role of a shared project vision, to bring to life the value that will be delivered by the project.

A shared project vision acts as the foundation for generating solutions but, critically, it also acts as the project's "True North" guiding the actions of everyone on the project. as it progresses.

A really effective vision is rarely handed down from on high, it is co-created together with customers and stakeholders. And in doing so, it reflects their needs and gets their buy-in.

The video uses two examples of visions that engage the senses and emotions:

• The Sony Walkman.
• The Apple iPhone.

The video also describes four tools that can be used to collaboratively develop a shred project vision:

• The product box.
• The movie poster.
• The cover story
• The TV Advert

This video contains a list of questions that will help you identify the key internal and external customers and stakeholders for your project.

The most effective project visions are usually those that are co-created with customers and stakeholders.

Exercise to identify customers and stakeholders for your project

This video introduces a simple customer and stakeholder mapping approach to prioritise management attention.

Engaging with customers and stakeholders throughout the life of the project, is vital for success. But if you've thought hard, in the previous exercise, you will have identified a lot of customers and stakeholders. And if that's the case you need to prioritise your attention, because you cannot engage with everyone, all of the time.

First we categorise customers and stakeholders by levels of interest and power. Respectively, how interested they are in the project and their ability to impact it, positively and negatively.

Having mapped these two dimensions, we can categorise customers and stakeholders as being:

• in favour of the project.
• opposed to the project
• neutral towards the project or positin unknown.

This mapping gives us a great visual foundation for where to direct our attention.

Summary slide for customer and stakeholder mapping exercise.

This short article describes a fantastic tool, from the discipline of Design Thinking, for helping to understand the motivations of customers and stakeholders.

I was really sceptical when I first came across it: I thought it was all a bit to "woo-woo" for a hard-nosed project person like me but it really opened my eyes to the role of emotion in projects and the role that Design Thinking in general can play. There's a lot of woo-woo in play in projects and we ignore it at our peril.

This video introduces two very simple "games" that we can play to open up thinking for generating solution options:

• the Star Trek game
• the venture capital game

Nobel prize-winning psychologist, Daniel Kahneman, tells us in his book, Thinking Fast and Slow, that the mind is "a machine for jumping to conclusions". Evolution has programmed us to think and act quickly, to ensure our survival.

But while this is great for survival, it is bad for complex decisions, such as finding a solution for a project. Our innate inclination is to settle quickly on the first plausible solution that comes along. And having done so, we seek out confirming evidence and disregard evidence that doesn't match "story" we have already decided upon.

The challenge in projects, therefore, is to restrain this strong instinct and find ways of opening up our thinking and keeping it open while we explore options.

As another Noble Laureate, Linus Pauling, tells us, to have a good idea, we have to have many ideas.

Slide for "opening up thinking" exercise

This video discusses why it is important to think about constraints when generating solution options.

There are three categories of constraints that should be considered:

1. Those arising from design decisions.
2. Those used to stimulate creativity.
3. Those used to define the delivery strategy.

The first category become visible during the solution design process, as we explore trade-offs between constraints, performance criteria, risks, assumptions and costs. The key thing with these types of constraints is to capture them, explicitly, so that they do not become hidden assumptions that restrict us. The circumstances that led to these constraints may change, so it's important that they are in full view, so they can be revisited at a later date.

The second category are those constraints that we can use to stimulate creativity - something that product designers do all of the time. Constraining cost and timescale are two great ways of doing this - I recommend that your always experiement with these and see what it yields.

But you can also try other constraints, appropriate to the situation. Remember Steve Jobs's vision for the iPhone was "to be able to carry the internet in your pocket". That's a great example of a constraint that stimulates creativity. And note that in that instance, the constraint is inherited from the vision - that often happens.

The final type of constraint are those that shape the delivery strategy:

• When is it needed?
• How much do you have to spend?
• Ensure the design can be delivered in regular chunks of value.

Slide summarising constraints exercise

This video discusses that critical role that business and IT-system performance criteria play in setting the agenda for generating solution options.

All too often, performance criteria are an afterthought in IT-based projects. And all too often the idea of performance criteria is applied only to IT-system performance, not business performance as well.

The key is to set out performance criteria that the solution has to meet NOT to design a solution and THEN think about what criteria it should meet. This is not dissimilar to the example of IKEA furniture being designed to be flat-packed. A lot of money could be saved by simply specifying up front that the solution has to be as fast and as easy to use as the existing one....even if its a manual one.

The video presents a rigorous way of specifying performance criteria based on the ideas of author and thinker Tom Gilb.

A slide that summarises the exercise, preceded by an example for ease, with one of the dimensions defined in detail.

The video discusses why it is important to capture assumptions and risks that from part of the various solution options.

Similarly to constraints, there are two types of assumptions:

1. those that we make as part of the solution design process
2. those that are inputs to that process, such as the business case assumptions

The video highlights that assumptions, performance criteria and constraints are actually very similar and often different ways of stating the same thing. Indeed, a reductionist approach would be to state them all as one of those three categories. We saw a similar thing with problem, need or mission.

But, as Apple's Sir Jonathan Ive, pointed out, the language that we use plays a critical role in shaping our thinking. The different terms (constraints, performance criteria and and assumptions) have different webs of associations. Each triggers a different perspective and hence different thinking.

A constraint is some that prevents us from doing something. A performance criterion is something to be achieved. An assumption is something neutral, whose flip-side is the risk of it not being true. I urge you, therefore, to experiment with all of them.

The video goes on to suggests some techniques for identifying risks, such as the fish-bone (or Ishikawa) diagram and psychologist Gary Klein's idea of a pre-mortem.

First slide has risk categorisation matrix and second slide has the assumptions and risks exercise.

This video presents a number of approaches for comparing alternative solution options.

If we have followed Linus Pauling's advice of generating lots of ideas, in order to find a good one, we need way of narrowing them down. But we also need to be cautious about jumping to conclusions, so need to follow Daniel Kahneman's advice to slow down our thinking, so that the logical brain is not crowded out by the faster, intuitive, animal brain. This video presents four different approaches to ranking the value of solutions.

The first two approaches are my favourites while iterating around options because they are quick and straightforward - in other words, easily done on the fly.

The first flows directly from the groundwork that we have already put in. We have already effectively created a value profile for each option, comprised of the combination of:

• constraints
• performance
• risks
• assumptions
• costs

Will simply put these in a ranking matrix and see which comes out best. But be cautious, there is no right answer. The means is more important than the end. The goal is just to get our logical brains into the game.

Another easy approach is that favoured by a lot of product designers. They often use a ranking systems based on:

• novelty
• usefulness
• feasibility

It's so easy to do quickly that it is worth doing alongside the value profile, to get a different perspective.

The third approach is based the ideas devised by Tom Gilb. It is more complicated and more granular approach but can be useful when you are narrowing down to a few options. It scores features individually, against desirable attributes, and combines them in different bundles, each representing an option. But if you like this approach, do take care that you don't drift into a features and functions driven design, rather than a value-based one.

Finally, there is an overview of Net Present Value, which is the best way to compare options from a financial perspective. This is really one for when you are down to relatively few options.

Slide summarising exercise for comparing solution options

Generating solution options is a collaborative process. This article will give you describe some tools that you can use to run effective workshops.

If you are still having trouble getting your head around Net Present Value then this standalone article might help. It repeats what was in the video but might suit those, like me, who prefer a more leisurely pace for concepts that are not initially intuitive.

This is the final main video of the course and talks about the key tools for managing delivery:

• the evaluation of chunks of business value.
• distilling the business case to one or two pages and using it to drive reviews.
• Earned Value Analysis - essential progress information on a single graph.
• High level Gantt charts.

1. A worked example of Earned Value Analysis.
2. An explanation of what is meant by "waterfall" and "agile" software development approaches.
3. A pretty long description of an agile approach named "Kanban" which is useful for all types of projects/

I hope you have found the course interesting and of value.

This video is a worked example of how Earned Value Analysis can be used to monitor progress. It's a great approach and much simpler than most people think!

This video is a primer, aimed at people who have heard the terms "agile" and "waterfall" but don't know what they mean. It's not a detailed "compare" and "contrast" exercise for those already familiar with the terms.

Agile is usually used in the context of software development and that's its origins, with the Agile Manifesto. So if software development is part of your project, it useful to understand what the terms mean.

I have increasingly heard people talking about "agile business change" but it's quite a loose use use of the term "agile", in a similar way that people bandy about the term "lean".

I am not knocking the idea of agile business change. Indeed, depending what is meant, it probably has a lot in common with the ideas in the course, But if in doubt about what is meant by "agile, look up the Agile Manifesto.

There are two main ways of managing agile projects at a detailed level:

• Scrum
• Kanban

If you want to understand the essence of scrum then this YouTube video of one of it's originators, Ken Schwaber, giving a talk at Google is a great explanation of the essence/intention of Scrum, without a lot of process-police stuff that it seems too have picked up over the last few years. Ken's talk is about an hour but it's good value.

If you want to understand Kanban, check out my next video in this course.

Kanban is gaining increasing traction as a way of managing agile software development. This video explains how David Anderson cleverly adapted Kanban, which is a lean manufacturing technique, for use for software maintenance and development.

Since the publication of Anderson's book "Kanban", others have applied the approach all types of project, including personal workload.

Kanban is particularly interesting for Lean Project Management, as "pull" and "flow" are key elements of the approach.

This free e-book contains seven thought provoking articles, to help you look at your projects from a different angle:

1. How to avoid poor project framing
2. What projects can learn from West Point Academy
3. Is your Project Sponsor in the audience or on the stage?
4. Why IT-based projects should embrace Design Thinking
5. Solutions: where IT-based projects go off the rails
6. Why organisational change needs gardeners not mechanics
7. A team of leaders for project success