Black Swans and Large Software Procurement Projects

Black Swans and Large Software Procurement Projects – Paddling Through Troubled Waters

In his excellent book of the same name, Nicholas Taleb describes a “Black Swan” event as having three key characteristics:

1. It is an outlier, as it lies outside the bounds of normal expectations and nothing in the past can convincingly point to the possibility of its occurrence
2. it has an extreme impact, and
3. in spite of its outlier status, basic human nature results in us making up explanations for its occurrence after the fact, thereby making it explainable and predictable.

Over the years I have been involved in many post-event reviews of software projects that have gone wrong. Invariably, the post-mortem points to a number of outlier factors that, in hindsight, were seen as key contributors to the failure. These contributing factors were also often viewed as being fully predictable; that is, their possibility should have been predicted and mitigated from the outset. However, in most cases, they were not.

The challenge for large organisations in delivering consistently favourable project outcomes is to harness the intrinsic knowledge and experience that exists within the organisation and combine this with relevant extrinsic knowledge to plan for and mitigate poor project outcomes. Intrinsic knowledge exists in the people who are currently employed in the organisation and may be further expanded through internal contract repositories, document libraries and so on. Extrinsic knowledge can be gleaned through personal networks, external consultants, professional research and advisory organisations and other generally-available sources such as company websites and the broader Internet.

Why do these failures keep happening?

So, with all this knowledge, why do these failures continue to happen? Is it down to individual or corporate memory loss? Do we, as technology Buyers, subconsciously block out bad memories and refuse to learn from previous mistakes? Or, is the churn amongst our specialist technology Buyers so high that we simply lose the experience and expertise that would otherwise help us avoid the slack selection processes and poorly constructed contracts that underpin many expensive technology failures?

One of the reasons why so many projects fail to a lesser or greater extent is the continuing failure to understand when the balance of power/advantage shifts from the Buyer to the Supplier on large software projects and to ensure that the Buyer’s leverage is optimised while the advantage is on the Buyer’s side. This is often about such factors as:

• not paying enough attention to internal communications processes and relationship building, leaving the door wide open to Supplier influencing
• not having the experience required to lead large procurement projects and processes from their inception to their successful conclusion
• allowing inordinate Supplier leverage through timeline-driven offers/demands, back-door selling and undermining of the buying process.

The challenge for the software Buyer is not just to bring in the right deal at the right price, but to be aware of and plan for the significant risks associated with delivering the project after the contract has been signed – and the best time to address these is when the advantage sits with the Buyer – before the contract is signed.

The diagram below shows the power trend and shifts for a problematical large software project across the sourcing, delivery and implementation stages as the advantage shifts from the Buyer to the Supplier. If the Buyer has not used his advantage to best effect during the sourcing phase, as soon as the contract is signed we begin the slide towards troubled waters.