A black swan refers to an event that comes as a surprise and has a major effect. Black Swan events are often then rationalised with hindsight, e.g. ‘looking back it was bound to happen’. Nassim Taleb was the first to formulate this theory.
In the project world, there are many examples of black swan projects, i.e. projects that appeared to be on track to deliver benefits but suddenly a realisation dawns, and these projects are terminated with the usual recriminations or hunt for scapegoats.
After the event, people who are involved in the project, with the benefit of hindsight, tell everyone that the project was always doomed. I am stretching the black swan theory a little to illustrate the point but I hope you will bear with me.
So, how can we avoid a black swan project?
Unexpected project failures often come about because project staff are painfully aware that the project has been doomed for some time and to them it is not a black swan event but one that is known and predictable. However, if there is a culture of fear, this can lead to a cover-up of the true project status.
This cover-up usually manifests itself in reporting to senior management that all is well with the project when the reality is that the project is screaming RED. Often a symptom of a culture of fear is the unwillingness to accept a RED status report; it must always be green.
Black swan projects can occur because what the sponsor or senior managers think is being delivered is different from what the project team thinks they are delivering.
A few years ago I was the programme director for relocating the head office of an iconic retailer to Paddington. The team thought they were delivering an office move but when I spoke to the CEO, the sponsor, he wanted to create a new culture and the new office was just a facilitator.
Once this was understood, we had to re-shape the programme to deliver the real goal. It is clear, if the goal or a project or programme is not agreed and understood by all parties, there can be a nasty surprise in store for the individuals who realise that what’s being delivered is not what was really wanted.
Many organisations have a delivery assurance function that assesses projects from an independent view. This is a good way to review the project and see if the project is on track to deliver its outcomes. Often the project team has a vested interest in looking at the project through rose-tinted or ‘beer –glasses’.
Even with evidence to the contrary, they assume everything will be ok and sometimes in extreme cases cover up a failing project.
There are some PPM tools and apps that we have developed that can help with delivery assurance.
Quality gates can take a number of forms but in simplest terms, they are a number of points in a project’s lifecycle when a steering committee or change board can decide whether to continue with the project or not.
Relevant documentation is checked, but the essential question that is asked is,” With what we know about this project now, shall we continue with the project? Does the business case still stack up? There may have been changes over time that means the project is no longer delivering the value that is needed. Or it could be that further along the project’s timeline, the original costs and/or benefits were too optimistic.
In some organisation where I have worked, projects are only funded to the next quality gate and the onus is on the project team to demonstrate – in an objective way – that money and resources should be allocated to move the project to the next quality gate. In less rigorous regimes that I have come across, projects are funded at the beginning (quality gate zero) and then it is up to the change board to stop them or actively withdraw funding.
The more rigorous regime of funding a project only to the next quality gate is, I think, better as it puts more emphasis on ‘shall we continue’ rather than – we have started so we must finish.
In my view, one of the reasons why there are too many black swan projects is that quality gates have not been used to check the health of a project at key phases. The result being that a big surprise happens at implementation or soon afterwards.
Projects are significant investments and to avoid a black swan project, there are, as I’ve described, some simple and inexpensive ways to ensure a shock or surprise does not occur. A black swan is defined as an unexpected event that when it occurs, everyone says with the benefit of hindsight that it was bound to happen. Many projects have unexpected outcomes, i.e. black swan events, that can be avoided if you focus on outcomes, carry out delivery assurance and implement quality gates.