How Big Things Get Done – What’s Systems Engineering got to do with it?

I finally got round to reading How Big Things Get Done by Prof. Bent Flyvbjerg and Dan Gardner which I bought last year. I’ve summarised some of my thoughts below on how to improve the likelihood of success for megaprojects from reading the book.

Systems Engineering Principles

This is one of the best books I’ve read that advocates a systems engineering and even a Model-Based Systems Engineering (MBSE) approach without talking about either. I think this is a useful resource in advocating for these with those who are unfamiliar with the concepts.

What did I learn about these from the book?

? Apply rigorous requirements and design validation to projects

? Surface mistakes early in the life cycle when they are cheapest to resolve

? Maximise the use of detailed virtual modelling in all aspects of the project

? Conduct extensive prototyping in the true meaning of the word (don’t put your prototypes into production, please discard them!)

? Use design reviews to conduct intensive scrutiny rather just as a tick box exercise.

Project Strategy

Where possible, avoid being the first to take on novel projects and instead find those who have and learn from them. The recommendation is to be a ‘fast follower’. If the project has been done before, then favour existing designs and avoid radical changes. Use proven processes and techniques as is or with minor modifications, or combine proven processes and techniques. A modular approach to projects allows experimentation and learning from repetition. This reduces risks in scaling delivery.

People and Culture

The book advocates staffing projects with a ‘masterbuilder’ who has deep domain expertise. Going one step further, one should also use experienced teams where possible even if this means contracting the expertise in. The cohesiveness of experienced teams is suggested to be a contributor to success. The entire project team should be coalesced into one team with effort and time spent building a unified project culture worth every penny. From an organisational perspective, teams who have delivered a relatively new project type should be allowed to gain progressive experience on the same project type. This builds upon what they have learnt improving project delivery over time.

Estimation

A large portion of the book is dedicated to project estimation with the Reference Class Forecasting approach being recommended. The idea behind this is that the large majority of projects are not in fact unique, which is a common assumption. One can use data from projects in a similar class to get better estimates than are possible using a bottom-up estimation approach. Reading this immediately brought to mind methods such as the Constructive Cost Model (COCOMO) and the Constructive Systems Engineering Cost Model (COSYSMO). An interesting point made in the book is that projects are often criticised for overrunning with less attention paid to whether the original forecast was actually accurate.

Risk Management

The larger the project cost, the more willing one should be to spend serious money on risk mitigation measures. Successful project delivery may require taking drastic actions as far reaching as changing contract terms to align interests of various parties and reduce project risk. Data shows that some project types inherently have much higher risk. Mean cost overruns for projects such as Aerospace, Defence, and IT (non-exhaustive) are at the higher end of the scale ranging from 60% to 73%. These project categories do not follow a normal distribution so mean overruns can range from 119% to 447% in the tail of the distribution. That means paying attention to historical outcomes of similar project classes is even more important for these project categories.

#DigitalEngineering

#MBSE

#Megaprojects

#ProjectManagement

#SystemsEngineering