Learn to how to run projects that deliver lasting business value NOT a meaningless list of milestones.
Don't be one of the regular crowd, whose projects fail to deliver what was expected, running late and over budget. Instead of the daily grind and stress of trying to keep things on course, imagine running projects that surprise customers by delivering regular value that customers can use, earlier than they expected.
I have devised this approach, from over 20 years experience of delivering complex projects and from in-depth research into project success and failure. It's my personal recipe for success and you will not find it anywhere else, either in courses or in books.
Conventional project management approaches pretend that projects are predictable. They focus on delivering lists of milestones or software releases that don't actually deliver any real, usable business value. In contrast, Lean Project Management recognises that projects are inherently unpredictable and structures your project to deliver, regular, usable business value throughout the project, not just at the end.
The approach that I teach in this course is applicable to all types of projects but is particularly useful for IT-based projects. This is because the output of an IT-based project is less tangible and less easy to define than something like a bridge. But equally, IT is more flexible than a bridge and thus lending itself to a lean approach.
The course is delivered as series of bite-sized videos, with accompanying notes and references.
In total there is around over 4 hours of video lectures and 17 straightforward exercises that ask you to apply what you have learned to “your own project". For those without a project they can used, a suggested "case study" is provided.
Ask yourself this questions: how do projects get to be a year late?
The answer is: one day at a time.
Don't let tomorrow be one of those days - sign up now and take advantage of the the 30-day money back guarantee.
This video describes the two frameworks that I will use in this course:
In doing so, I'll explain where the term "lean", and the associated five principles, originated.
In your experience, how many projects deliver what they said they would, on time and on budget?
This video makes the case for a new approach to delivering IT-based projects.It does so by pulling together the key independent research on project success/failure. It shows that the track record of project delivery is truly dismal.
The key research referred to is from:
I chose these sources because they are reputable and published publicly.
This video takes a look at the underlying causes of project failure:
To illustrate the universal nature of these problems, it cites the example of "The Universal Credit Programme". This is a flagship UK government programme that commands all-party support. But despite it's high profile and commensurate level of attention, it has still succumbed to the same problems that afflict most IT-based projects and programmes. The video quotes a damning report by the National Audit Office.
The term "Optimism Bias" was coined by psychologist and neuroscience, Tali Sharot and you can watch her TED talk on this topic.
Optimism Bias is a close cousin of the "Planning Fallacy" which was described by Daniel Kahneman and Amos Tversky. It is also closely related to the "Overconfidence Effect", described by Kahneman in his epic book on judgement and decision making, "Thinking Fast and Slow".
The video clip about the Space Shuttle is taken from the 1998 BBC documentary, " A Major Malfunction".
As we have seen, the delivery record of IT-based projects is poor. But when it comes to our own projects and our own business outcomes, our optimism bias kicks in. Too often, we spend money on IT as a first rather than a last resort. Not really very objective, given the risks . If we think harder there are often alternatives.
This article describes some common scenarios where an IT-based project could have been avoided or at least minimised to a great extent.
This short article is aimed at those of you who are professional project managers. It asks where you see the boundary of your responsibility. Is that boundary set by the "iron triangle" of time-budget-quality or something more?
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:
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.
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":
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.
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.
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 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.
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:
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:
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 video also describes four tools that can be used to collaboratively develop a shred project vision:
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:
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:
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:
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:
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:
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:
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:
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:
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:
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:
Gary Lloyd has been helping businesses to deliver strategic, IT-enabled change, for over 20 years. His roles have ranged from being the business leader who drives the change, through to being a trusted advisor to CEO's and COO's, helping them to get value from their projects, programmes and ventures.
He is principal consultant at Gardeners not Mechanics which specialises in organisational and personal change.
He is a member of the Executive Coaching Panel at Warwick Business School and a member of the School's Mentoring Steering Committee.
He is author of Business Leadership for IT Projects which was published by Gower.
He has also published articles in Project Manager Today, the BCS professional members journal ITNow, and was contributor to Digital Leaders, published at the end of 2015 by the British Computer Society, the chartered institute for IT professional in the UK.