I read a recent post from the UK’s Infrastructure Project Authority with interest. Within the post they describe 3 lessons learned for future infrastructure delivery:
- Behaviours and culture are more important than process
- We need to get real with optimism bias
- We must pay greater attention to systems integration
I then read the report from the Department for Transport on “Lessons from transport for the sponsorship of major projects”.
I’ve collated a list of ~20,000 lessons learned and I must admit that none of the observations in the DFT report comes as a surprise. I believe that most of it won’t come as a surprise to project sponsors either. Sponsors are typically trained through the government’s Major Project Leadership Academy, hence, there is a reasonable expectation that they would be aware of these issues.
I fear that we are trivialising the challenge when we summarise it to lists of the top 3, top 24; Linkedin is swamped with opinions on the top 5, 10, 50. Ed Merrow’s book on industrial megprojects lists 7 key mistakes, OGC published a series of reports, the Scottish government publish a list of lessons from assurance of major projects. New Zealand and Australia do the same, the APM publish 12 conditions for project success.
I worked with Dr Stephen Duffield on research into lessons learned and we concluded that it is generally ineffective within a project delivery context. Our paper can be found at this link.
Lets stop giving the illusion of learning
The lessons learned process has existed within project management for over 40 years. Yet the evidence points to the fact that it is ineffective. Polishing the process doesn’t change it. We need a different approach.
Its actually not that difficult to fix.
If we evolve from lessons learned to learning from experience we open up a wealth of new possibilities. Learning from experience is essentially at the heart of machine learning. Its not deterministic – i.e. learn all these lessons and apply them to every project; it is probabilistic, which of the previously experienced observations are likely to occur at a specific point in a project and what is the distribution of impact.
Isn’t this exactly what we are trying to understand?
But the phrase ‘learning from experience’ implies that we learn from one project to the next, which is something that implies human learning. I prefer the phrase ‘leveraging experience’ because we are looking to leverage the experience of the projects that have gone before.
Lets stop using descriptive summaries as a means of learning
When we talk about leveraging experience, are we seeking to extract the descriptive summaries that sit in lessons learned logs; summaries such as “Invest in building relationships between leaders”. I would suggest that they are a gross over simplification of the reality of a major project and trivialise what is a complex and inter-related challenge. Descriptive summaries may help with communication up the management chain, but history has shown us that as a profession we don’t learn from them.
Instead, lets create a network of data that enables us to predict when certain situations, risks or issues may occur. When is the likelihood such that we are compelled to take action? Having lists of lessons creates a tick box culture; a blunt instrument when advancements in data science enable us to take a more evidenced based approach.
Data trusts rather than lists of lessons
I reflected on the department of transport report. Did it capture the >10,000 lessons learned from Transport for London, or the ~100 lessons from the DFT’s disastrous South East Flexible Ticketing Programme, rail timetable challenges of 2018, rail franchise challenges, Crossrail learning legacy. I could go on.
But we boil all this rich and hard won experience down to 3 lessons learned. Its hugely frustrating.
I am working with the UK’s Oil and Gas Technology Centre and Oil and Gas Authority to develop a data trust for project delivery data that reaches across the oil and gas sector. We are mobilising a similar arrangement for construction too.
As projects proceed through their lifecycle they create an exhaust plume of data that is a by-product of delivery. Projects such as Crossrail develop huge amounts of data, including details on over £4billion of risk drawdown; yet this data will be archived when the project is complete. This data has tremendous potential for other construction projects such as HS2, Network Rail, TfL and the supply chain, but there is a nervousness about sharing it without the appropriate controls in place.
By pooling, connecting this data and applying advanced data analytics/AI we are able to analyse the data to develop predictive insights and recommendations, tailored to the phase and specific circumstances of the project. From the forensic analysis of lessons learned, snags, logistic analysis, impacts of weather through to understanding the probabilistic distribution of risk based upon actual out-turn from previous projects, we are able to highlight areas of focus, increase rigour and challenge bias. Such an approach has the potential to transform how project professionals value project data, which creates the momentum for an upwards spiral in data quality and ultimately, the quality of insights.
In order to address commercial and reputational concerns we need to create a trust that partitions the data and provides trustees with confidence that they can control who can see which elements of their data. An open data solution will never work.
Lets be bold. Lets transform how projects are delivered.
Its time to make a difference.
Martin Paver is the CEO and Founder of Projecting Success, a consultancy that specialises in leveraging project data to transform project delivery. He has led a $1bn megaproject and a multi $billion portfolio office. He is the founder of the Project Data Analytics community, comprising nearly 3000 members who share a passion for leveraging the exhaust plume of project data. He regularly blogs and presents at international conferences, helping to ignite the professional imagination and inspire change.