(VUCA = Volatility, uncertainty, complexity and ambiguity)
(c) Steve Peacocke
In good times, projects were predictable.
In good times, we knew what we were building and could plan months, if not years out. Projects consisted of known elements, and it was the Project Manager’s role to ensure that changes didn’t come along to upset the apple cart.
The Gantt chart was king, resources could be planned, and reporting was based around the variances from the plan.
In good times the Business Analyst and Project Manager would work for months to gather all the requirements, document them, gain agreement from all the stakeholders and draw up a plan well before any serious money was spent. Once approved, the Requirements Document was frozen and the Gantt chart was baselined, which means that the original plan will never change and you can compare actual with planned on the same chart as the project progresses.
Everyone was happy. The stakeholders knew exactly what they were getting; the sponsors knew how much finance was needed.
What happened? Why has this utopia changed?
Whether the world was ever this utopia described above is subject to some debate. However, one thing that I’m sure we can all agree on is that currently, we all live in an increasingly Volatile, Uncertain, Complex, and Ambiguous world – a VUCA world.
Project Managers found that things genuinely do change. No longer can the world be predictable enough to implement even a 3 or 6-month project with any certainty. The idea that Project Managers should place all these controls around change, means that the final product may not give much in the way of benefit.
In a recent survey of more than 10,000 projects, the Standish Group asked the question: “Of the functionality which was delivered, how much of it was actually used?”, and found a disturbing 45% of the features implemented in the final product were never used (reference here – page 15).
Think of that – almost half of the time that the team worked long hours for, was to implement things people thought they “might” need and had to get it into the requirements before they were “Frozen”.
almost half of the time that the team worked long hours for, was to implement things people thought they “might” need but never used
This, and other feedback on project delivery means that Projects were failing. Something needed to be done.
That same report looked at projects being managed with more modern project management ideals were far more successful.
Using the old project management controls, an average of 29% of the projects failed, and just 11% were classed as successful – just 11%.
Now compare that with more modern practices, and the figures change drastically. Here they found that only 9% of those projects failed and 39% were classed as successful. That’s a total turnaround.
Old style Project Management: 29% Failed; 11% successful
Modernised PM run projects: 9% Failed; 39% successful
Time for us all to sit up and listen!
So, what is this new “Silver Bullet”. The answer turns out to be both simple, and extremely complex to implement. One major problem is that the drive for certainty is still inherent throughout business despite the clear evidence that there simply IS NO certainty. It requires us to look at the world in a totally different light. It’s a change of perspective.
The Rules of the Universe
There are the known rules in the universe:
- Things will change – and these are changes we want to take advantage of
- The customers and stakeholders don’t know what they want – But they will know if they can see it being put together and help with direction
- The builders don’t know how to build it – this relates to #1 and #2. They simply don’t know yet what they should build because; things will change along the way, and customers and stakeholders are unreliable predictors of the final deliverable
It’s not just about coping with change. The old style of control had lots of documents around ensuring that changes are tied down and boxed away. This had many undesirable outcomes like not including some necessary things that only came to light two-thirds through the project, and the previously-mentioned pile (45%) of things that nobody wanted but had to go into the requirements or miss out.
And this leads to yet another rule of the universe:
- Just because you deliver a project on time and under budget, doesn’t automatically mean anyone will want it.
And that last one highlights the next area under discussion – Value.
Very little in that project plan; the charter; the 1200-page requirements document, or any of the other documents you produce concentrate on this thing called “Value”. Now before you jump up and down and tell me about the stakeholder whiteboard sessions, your 60-point before and after process maps; and your defined list of tasks; let me ask you why you are defining the entire project at the time when everyone will know least about it?
why are we defining entire projects at a time when we know least about it?
Yes, that’s right! Before the project starts, you will know the least about what constitutes “Value”. Customers and other stakeholders don’t yet know what they are going to get – sure they’ve described in detail some solution that they see in their mind, but are you delivering that product, are you even solving a problem, and are you delivering any real, known, and verified value?
So how do we know what value is at the start of the project? Well here’s the bad news, we don’t. We find out as the project progresses. In the old style, that’s too late, but in a modernised project, that exactly what we want to do.
Your View will Change as the Project Goes On
So how do we instil this “Modernised Project Management”? It takes a different view from all levels.
- Continually organise work with the next most valuable thing. Continually.
- Operate the project with the known fact that things WILL change. Update your project plan continually.
- Visualise the workflow so that everyone knows what is happening.
- Continually improve with regular project retrospectives, not just at the end when no-one is left, and no-one can take advantage of the lessons.
Work in set cycles from a couple of weeks to a month. The shorter the better to keep everyone involved in the project.
The Next Most Valuable Thing
If we are always looking to the next most valuable thing, we can concentrate on delivering the most value always. Deliver that value and you can now concentrate on delivering the next most valuable; and so on.
This way of working has several advantages:
- Change is allowed. In fact, change is welcomed.
- Stakeholders can see and understand what is being delivered and give feedback. Everyone can then find out what is of real value when they start seeing and hopefully using, the first iterations of the product.
- We no longer work for months before someone realises we may have misinterpreted something or something just doesn’t work as planned in real life
- Customers and stakeholders get real value early – This results in on-going quick wins that build a full product in the end
- We don’t waste time building stuff with no value
One of the most important things about delivering in this way is that it allows the customer \ stakeholders to decide that enough value has now been delivered and any further project work can be put aside, or added to the next project. This means that your project may be delivered well under time and budget and that your stakeholders are very happy with the outcomes.
Things Will Change
Knowing that things will change, we can plan accordingly. Spending 3-6 months planning all the intricate details of a project is no longer feasible. It’s a waste of time, energy, and money, if we know that things will change.
The modernised way to plan a project is to time-limit the planning session to under two days and get the whole team involved with the stakeholdrs in that planning. This limited time, all involved way of planning will deliver an understanding of the project functionality and some initial plan of delivery.
I’m not talking about a Gantt chart here. While some constructions project may still need this level of planning, for most projects, this chart is invariably a time-consuming piece of work itself that simply focusses on tasks and limits change. We want to focus on value and delivery, and we want to embrace change so that we can deliver the best value to our stakeholders, and deliver it early.
An overall plan is generally enough to for the Sponsor (who generally only needs this level anyway and won’t read that 1200-page document). Funds are allotted and work on the very first iteration of value can begin.
The good thing for the Project Sponsor here is that they can redirect those funds if it turns out that the project is not delivering value at all. In other words, while there is still an overall project view, we can only concentrate on the next delivery of value. The risk is reducing as we go along, rather than increasing like before.
That overall project plan can also be recreated at regular intervals showing the actuals rather than forcing the plan.
Visualise the Flow of Work
Taiichi Ohno, a Japanese industrial engineer and businessman from Toyota made famous one of the most widely used business visualisation tools. Originally taken from a simple stock replenishment system, Kanban is a Japanese word meaning billboard or signboard and was used in Toyota manufacturing before being generally accepted in other business production systems. The visualisation comes from the cards (tasks) which are moved from one column to the next as the work progresses.
The picture is an example showing a Kanban on a recruitment work flow with WIP limits (see below) in columns 2 and 3.
This visualisation board can help progress items, can be seen at a glance, and changes to focus to the flow of work. It shows work that is yet to begin in a prioritised column, then progresses through the stages of work until it reaches a final “Done” column. One of the most used is a simple 3-column board showing work that is To Do; In Progress; and Done.
One of the rules for Kanban is limiting the amount of work in progress (WIP). WIP limits help us to concentrate on delivery rather than work. The focus is therefore on the flow rather than the individual tasks. Kanban then not only helps is to visualise what is happening, but very quickly and visually makes blockages apparent.
It has been said that “the problem with visualising the workflow is that it highlights problems”, followed immediately by “.. but the good thing about visualising the workflow is that it highlights problems”.
It is only when problems are found, can they be resolved. We can see when an item is not moving and can ask the question “why”.
Think about this a minute. Not only are we concentrating on the flow of work to Done; but we also focus on clearing blockages and resolving problems to make the flow of work smoother.
This form of visual display is not just for making cars and stocking shelves, it now a fully-fledged management tool for all types of projects.
See and Understand
At regular times (at least once a month, every two weeks is optimum), the team will show everyone and anyone what they have done so far. Ideally, this will result in a sub-release of the product being built so that the end users can also give feedback.
This show involves, stakeholders, project members, customers, other teams, anybody.
Although this is usually a short display, several things are happening here:
- Stakeholders and others can see, understand, and make comments that might direct the team towards the next most valuable thing.
- The Project Sponsor can assure themselves that what they are paying for is valuable.
- For the first time in history, the build team is not only able to show others what neat things they have done and how they’ve resolved some wonderful problems to come up with snazzy solutions, but they can see the result in the stakeholders’ eyes. They can discuss slight changes that might make for better value. They can also get direct feedback from their peers on the team.
- The team can then reassess the value of the currently planned “Next Valuable Thing”, and perhaps teak those plans.
Stakeholders can see what they’ve asked for and help direct the project. There’s a saying “I’ll know it when I see it”, and this is most prominent in these sessions.
It is these sessions that allow us to track against expectations. The team will only be building the wrong thing for a single iteration before they are told “That’s not what I meant”, and can make changes far more quickly.
One more thing can happen at that showing: the sponsors, stakeholders, and the customer can then state “That’s great, we love what you have built, we can use that and that’s enough, we don’t need to spend any more money on this”. The team can then celebrate a great success before they start on their next project.
A Change in the way we Deliver
Remember I said “So how do we know what value is at the start of the project? Well here’s the bad news, we don’t”? This modernised project management understands this, and the early iterations allow the team, the customers, and the stakeholders to see and find out what is most valuable each time, continuously.
In this way, we get to understand the graph below.
The red line represents the old way of managing projects. Here there is no value until we deliver at the end. The value may not be as much as the blue line because this was defined before we even started the project when we knew the least.
The blue line strives to deliver value continually. We won’t always get it right, which is why the early rises are bumpy. However, eventually, the team and stakeholders understand how the project can best deliver that value and the curve goes up.
At any time, the stakeholders can decide that they have been delivered enough value (green dotted line) and that further spending and further time is not going to make that much difference. They decide to bring the project to an end early as a resounding success.
We can all wish we were back in a predictable world again where the Gantt chart and the clearly defined project plan were able to define success – even though history tells us that didn’t happen very often. The volatile, uncertain, complex, and ambiguous world in which we live, means we can no longer deliver those projects like we used to.
However, this new norm we are entering means better and more valuable returns delivered sooner.