Host Riccardo Cosentino explores untapped knowledge in project management, drawing from his Oxford insights. This episode of Navigating Major Programmes delves into integrating social sciences and complex adaptive systems, addressing how minor changes can lead to significant impacts due to project complexity. Join Riccardo as he navigates through the complexities of project management, offering innovative solutions to embrace and manage these challenges effectively in a new mini series: The Science of Complexity. Could your approach to project management be outdated? "I am convinced that, although we have achieved many incredible things already as project leaders and managers, there's something missing, something that's already out there in the world's knowledge that we're not using well enough." – Riccardo Cosentino
Host Riccardo Cosentino explores untapped knowledge in project management, drawing from his Oxford insights. This episode of Navigating Major Programmes delves into integrating social sciences and complex adaptive systems, addressing how minor changes can lead to significant impacts due to project complexity. Join Riccardo as he navigates through the complexities of project management, offering innovative solutions to embrace and manage these challenges effectively in a new mini series: The Science of Complexity. Could your approach to project management be outdated?
"I am convinced that, although we have achieved many incredible things already as project leaders and managers, there's something missing, something that's already out there in the world's knowledge that we're not using well enough." – Riccardo Cosentino
Steps for improving the management and understanding of complex, large-scale infrastructure projects:
Mentioned Links:
The Fifth Discipline: The Art & Practice of The Learning Organization (Recommended Reading)
How Understanding Systems Thinking Changed My Career (Riccardo’s LinkedIn Article)
Organizing for Work (Recommended Reading)
Nassim Nicholas Taleb’s Published Works (Recommended Incerto Reading)
Digital Construction Ontologies
The conversation doesn’t stop here—connect and converse with our LinkedIn community:
[00:00:00] Riccardo Cosentino: You're listening to Navigating Major Programs, the podcast that aims to elevate the conversations happening in the infrastructure industry and inspire you to have a more efficient approach within it. I'm your host, Riccardo Cosentino. I bring over 20 years of Major Programme Management experience. Most recently, I graduated from Oxford University's Saïd Business School, which shook my belief when it comes to navigating major programmes.
[00:00:34] Now it's time to shake yours. Join me in each episode as I press the industry experts about the complexity of Major Programme Management, emerging digital trends and the critical leadership required to approach these multibillion-dollar projects. Let's see where the conversation takes us.
[00:00:53] Hello everyone. Before we dive into today's episode, I wanted to share a quick note. You might notice that the audio quality in this episode is a bit different from what you're used to. That's because I experimented with some new technology and used a voice clone to record it. While the quality isn't perfect, I thought it would be interesting to explore how this technology works.
[00:01:15] Thanks for your understanding and I hope you enjoy the episode. This podcast has been AI-generated using my cloned voice. I am on a journey to understand how projects can be understood as complex adaptive systems. I want us to be able to run projects as well as they can be run given the inherent difficulties.
[00:01:34] I am convinced that, although we have achieved many incredible things already as project leaders and managers, there's something missing, something that's already out there in the world's knowledge that we're not using well enough. You may have noticed this common theme on my podcast, but today I make it explicit, as I start to chart this journey so that others can join me, follow my journey so far, and perhaps avoid the odd wrong turns along the way.
[00:02:06] So, alongside the interviews and deep discussions at the core of my podcast, I will run occasional solo podcasts to keep you up to date with this journey. To begin, I have experienced all sorts of problems on major projects over the years and no doubt so have you, mixed in with the successes and the incredible dedication of those we work with, but failures, nonetheless.
[00:02:31] However few they are, they are what grab the attention, and that has been my starting point. Step one, social sciences and complex adaptive systems. As listeners know, Oxford opened my eyes to the behavioral, social, and organizational aspects of projects. Oxford also emphasized projects as being made up of systems, but they are systems that adapt and evolve in good and bad ways, and they display non-trivial unpredictable behavior that many call complex.
[00:03:05] Could this be the answer? Perhaps I could bring social science expertise into projects and learn from the practitioners of the various sciences of complexity. By complexity, I mean behavior that changes almost unaccountably with the scale of the project or changes because of its numerous interactions between its many parts, or because a small change in the inputs brings a big change in its outputs.
[00:03:37] The famous butterfly that flapped its wings look promising, but social science and complexity each cover a myriad of things. Where to start? The combination of both is attractive because some projects feel complex in how they change over time. And we know that much of the complexity comes from people and their interactions.
[00:04:00] Step two. Anyway, I began with systems thinking. It seems to touch both the human and social with its emphasis on spotting patterns in the behavior of groups. And it is a once effective in helping you see patterns of complexity. What do I mean? Well, typically systems thinking helps you see some business action being taken where there is some unintended consequence that ultimately counteracts the original action. For example, a project may increase staff numbers to accelerate the project, but if the new staff need lots of training by the current staff, then the project may actually fall further behind. This is a common pattern that Peter Senge calls the limits to growth pattern or archetype.
[00:04:50] There are several more patterns listed in his popular book of the 90 since the fifth discipline. This particular one involves individuals or an organization negatively reacting to the change. Once you start to see feedback loops between people and teams, you see it everywhere. The original sciences came from control systems, like how an airplane automatically adjusts its flight parameters, anticipating how the environment reacts to changes in flight angle and so on.
[00:05:19] So, systems thinking in the business context uses both social science and the science of control systems to make the business world more predictable. So, some project behaviors, which would otherwise look complex, now feel easier to understand and navigate. If you'd like more on system thinking, I've attached a link to my 2021 article.
[00:05:43] I also refer to Peter Senge's Fifth Discipline in my reading list linked in the notes. Let's recap Step 1, social science and complex adaptive systems. Step 2, systems thinking. Have we arrived? Does this give us [00:06:00] enough tools to understand the strange behavior around us, sometimes on projects? Maybe. Maybe not.
[00:06:07] How will I know when I have arrived? When I understand enough? I decided to specify more clearly what I am looking to understand about complex projects. And then set a first success criterion. That's Step 3 and Step 4. Step 3, a Betagon chart. We run big projects on planned schedules. But there are still problems with this approach.
[00:06:29] I would like to understand projects well enough that I can rely on the scope and schedule nearly every time. To me that feels like progress, like then we really would understand projects complex or otherwise. Henry Gantt was writing just after the first world war and his gift to projects has served well for a century.
[00:06:53] I've attached a link to his key book on this in the notes for historical interest. It won't help you write better schedules today. We have come far. I think of P6 Nodes and Links and Plan and Foresight, for example, but I don't feel like we have fully arrived yet at a project plan that I can rely on nearly every time, that maybe that's what I'm looking for.
[00:07:13] This objective gave me more focus on my personal journey to better projects. So, how will I know when we arrive at a better project plan? I realized I needed a criterion for success. Step 4, finding a success criterion. I've always felt that when I can see it in numbers, when I understand the relationship mathematically, then I can be confident.
[00:07:38] That would be the criterion I would adopt. Can I just describe something in words, or can I actually run the numbers? I want quantitative explanations, in other words, not just qualitative. I have sent some hesitation about this, during discussions, and I may circle back, but this is my first criterion. Step 5, network graphs.
[00:07:57] Now, I knew where I was trying to get to. I began to look around, content to turn over stones one at a time until I could get a good lead. Schedules as network graphs appeal to me straight away. The work activity is a node in a network. And spreading out behind each node are incoming dependencies from other activities and stretching in front are outgoing dependencies.
[00:08:21] These dependencies fall along what are called edges in the network or graph. It allows you to think visually right away as if you're drawing lines on a whiteboard. Crucially, it treats relationships as first-class citizens in both analytics and visuals. You can see highly connected nodes and clusters of activities.
[00:08:45] And now there are such things as graph databases. It is straightforward to go from a tabular representation to a graph representation or vice versa. There are also algorithms created in something called graph theory, which you can run. For example, you can find shortest paths between two distant nodes.
[00:09:04] I investigated two key companies in this area, nodes and links and plan both use networks extensively. The methods are quantitative, so they meet my success criterion. Have they been successful at delivering a step change in a better Gantt chart? I think the answer is by and large, yes, but there is, clearly, further they are planning to go and there is more performance to unlock. So I put a market watch to check back on these 2 companies in future. On to the next step. Step 6, higher level network graphs. The last step led me to discussions, which revealed that conventional node edge graphs is only the 1st round of the ladder of network-type thinking.
[00:09:48] For example, each edge or relationship is only attached to two nodes or entities. To choose a simple example, say, you have had a graph of interviewers and interviewees as nodes with edges standing for someone interviewing a candidate. If Bob and Sue both interviewed Sharon at the same time, you can't express this.
[00:10:06] You can only draw a line from Bob to Sharon and a line from Sue to Sharon. Graphs, which do capture these more interesting sorts of edges are called hypergraphs. This look promising for making sense of the tangled relationships we see in complex adaptive systems. So I made a note to return to this when I had made more progress finding the types of project relationships I would like to map in complex projects.
[00:10:34] So far, this journey has been more or less via mental associations. As we go, we will continue to beef up our methods for the journey itself. So for the next step, we will move across to the ideas of Nassim Taleb, but we will get there by using one powerful computer science idea, that of Breadth First Search. BFS, along with its cousin, Depth First Search, are search algorithms.
[00:11:02] Breadth First Search means you search everything near to you, and then move one step out, and search again, and so on. Whereas, Depth First Search means that you choose one direction and follow it as far as you can go. When you can't find anything, you make your way back to the start and follow a new direction.
[00:11:23] These useful at different stages of exploration, because you get very different results, but now I am using Breadth First Search by going back to the start to social science and complex adaptive systems and moving one step from there to Nassim Taleb and the Incerto. Step 8, the Incerto. Most of you will be familiar with one or other of Taleb's books or concepts.
[00:11:48] There is The Black Swan, Antifragile, and so on. This step is just called the Incerto because he has a network of related ideas and altogether he sees himself as having written a five-book series called the Incerto. The blurb reads, while there is inordinate uncertainty about what is going on, there is great certainty as to what one should do about it.
[00:12:11] We have reached this step straight from the very first complex adaptive system step, because Taleb is a thinker of complexity. Two touch points of many for me on this journey are his work on extreme value theory and his notions of antifragility. Extreme Value Theory, or EVT, is a way of analyzing unlikely events rather than just treating them as deviations from the average result.
[00:12:37] I am hopeful this will open up better ways of treating the likelihood of project schedules. Antifragility, to quote from its blurb, is that category of things that not only gain from chaos, but need it in order to survive and flourish. I am hoping that a subset set of our programs could be set up to be antifragile.
[00:13:00] EVT is robustly quantitative, so that meets my success criterion, and antifragility could be, but I have not yet waded through Taleb's maths to find out. Step 9, digital twins. Another early line of inquiry jumping straight off from the ideas of complex systems and system thinking was the increasing buzz around digital twins in construction and engineering sectors.
[00:13:26] This was notable to me in that some work was happening rather than just research. And it had jumped into the sector itself rather than as sometimes happens construction being the last sector to know. Digital twins can be used during design, manufacture, installation, and commissioning. But crucially for me, with my interest in operations and maintenance, twins can also be used for the asset once it is operating.
[00:13:53] Could digital twins somehow force project schedules to engage with ground truth by providing ongoing models, visuals and readouts of what was happening at the site itself, even during operations? The digital aspect would give me the quantitative aspect I'm looking for, often, with data which is best of all, but it raises questions for me.
[00:14:16] One, how far this had got beyond the links with building information models or BIM? Two, how do we reliably combine models or systems or different types into one twin? The last question led me on to my next step. Step 10, composable systems. I have noticed generally in the industry that there are many different models supporting different design documents, often using overlapping parameters.
[00:14:45] And yet models often only influence each other indirectly. This happens via the sharing of design documentation and change control. Thankfully, the professions do their job well. And for typical designs, there is an established pattern for collaborating between disciplines, complying with standards, even if sometimes this seems to result in slower projects than you would hope.
[00:15:11] The problems come with unusual or novel projects or those requiring many constraints and engineering disciplines, especially where the suppliers aren't used to working with each other. This sort of situation can be optimized, but only tends to do so within an incrementally improving manufacturing environment rather than on large, one-off projects.
[00:15:37] In these situations, one anti-pattern can be different people wanting one definitive model. So they treat their own preferred model as being the key model, and all the other models as being more or less incidental, either pulling in static data from other models as a one-off or ignoring the other models.
[00:15:58] Where conscientious efforts are made to integrate data from models or make them consistent, these can tend to suck effort and time from key staff and sometimes end in efforts to create builds to complicated data pipelines after trying to match up data schemas, occasionally resulting in failure followed by the request to start all over again with one brand new integrated model.
[00:16:24] System engineering, architecture and integration, along with robust design management. are clearly the first line of defense in getting this stuff right. Model-Based Systems Engineering, or MBSE, is an emerging field showing a lot of promise. Looking a little further ahead again, Composable Systems may eventually provide the concepts and tools we need.
[00:16:45] Composable Systems is my name for the exciting field of applied category theory, which started as pure maths in the 1940s and has now influenced every single area of mathematics applied to the real world.
[00:17:00] Let's talk about why it's needed at all. After all, composition seems straightforward, we think we are used to decomposing systems, after all, into their constituent parts on the whiteboard.
[00:17:11] So what was the problem? The problem is that we don't think hard enough about relationships and behavior across interfaces. So we don't tend to agree on which parameters are preserved as you move across the boundary between different types of systems. That's a problem with composing horizontally which can be thought of as gluing systems together. It's also a problem with composing vertically. In other words, when we draw a boundary around several components or subsystems at once and treat everything inside the boundary as being one larger system, interacting with other larger systems. For example, we might move from the detailed drawing of car braking system to the more general drawing of the whole car where the brakes is just shown as one box interacting with other boxes, such as the steering system also represented as one box. When we go up a level, we often leave smaller, unintended interactions between subsystems out of the picture, so that when we run the model at the higher system level, it simply does not match real-world behavior.
[00:18:21] The behavior of the whole system is unfortunately not the simple sum of all of the subsystem behaviors. Composable systems use category theory to specify exactly how to compose horizontally and vertically. It does this for dynamical systems, probabilistic systems, learning systems, mechanical systems, and so on, treating these all differently.
[00:18:44] It makes clear which promises it can and cannot make about overall system behavior. In the long run, composable systems will be needed to underwrite the promises made by digital twins. There's another thing that may be needed to make digital twins work too, but also can help us right now, and that is Step 11, semantics and Ontologies.
[00:19:06] Okay, stay with me, this isn't a linguistics class. There's a whole body of work that we hardly use in projects or engineering. The stuff is ready to go. And it makes it much easier to cooperate on what all those thousands of pages of specification actually mean and how those words actually cash out in terms of objects, actions, properties, and intentions, the stuff is strong enough to reason with, and also comes with its own data schema.
[00:19:35] So it's straightforward to implement. Let's step back. Once someone has broken down your sector into its main disciplines, tasks, trades. They can save it in a logical structure of words or semantics that can be reused. The more low level structures have funny names like RDF, semantic layer, taxonomies, and the like.
[00:19:57] The higher level structures might be called ontologies or knowledge representation. Luckily, that person can save their expertise as low level or high level or both. It doesn't matter because Both levels talk to each other, and then anyone can go use this structure and apply it to their capital project, whatever type it is.
[00:20:19] Look up digitalconstruction.github.io, for example. It's in the show notes as well. There you will see a fully realized structure like this for construction. But it's not just the words and the diagrams you see on the web page. The web page itself is written in these logical structures such that a computer can understand it as well as a reader.
[00:20:43] And it doesn't stop there. You can pick and choose these structures. There are many of them out there for all sorts of disciplines and functions and use a mixture of them. You can add bits of structure yourself. It will draw you diagrams and then almost magically you can add your detailed data for your particular project, names of people, suppliers, building names, different building components. They all sit neatly underneath the overarching structure. Because it is a logical structure, you can also automatically check that your design or program arrangements complies with the rules that matter to you. For example, you could mandate that every piece of equipment on site can only be owned by one of six suppliers, or that every work team must have an objective.
[00:21:35] Now, I hope you can see how useful this can be right now, because semantics and ontologies are a mature field, but projects use them much less than, say, medicine or software engineering, and it would boost any digital twin, because you could attach semantics, in words people understand, to each of the component models.
[00:21:57] Let's review progress and look ahead. We began wondering where to start with thinking about projects as complex adaptive systems as projects. We saw how social science and system thinking help us to see complex patterns in cooperation on projects. To keep ourselves grounded, we said that ultimately we want quantified project relationships and better Gantt charts.
[00:22:25] Quick out of the gate, we saw that structures like network graphs and hypergraphs, search algorithms like Breadth First Search and Nassim Taleb's work on antifragility and extreme values, that is ranges far from the average value, all have something to say on the mathematics of project planning in regions of higher complexity.
[00:22:47] Whatever mathematical models we might ultimately adopt, they need to be brought together to relate directly to different parts of a complex project. This is where we turn back digital twins for construction subject of previous podcasts. MBSE, or Model-Based System Engineering, helps us here. If you push this to the limit, you will need the power of applied category theory to compose multiple systems together in a digital twin.
[00:23:18] We ended up at semantics and ontologies as being another way of boosting the predictability and explainability of digital twins, where languages like RDF and L come together in a semantic layer for a project and its digital twin. For project staff, this cashes out as a verified knowledge graph they consult on their complex project. I'm happy with the start. I made individual steps along the way, need more 1-to-1 attention, so I'm pleased to announce that there will be a mini-series of deep dives covering one new topic at a time related to unraveling project complexity. Each will be no longer than 50 minutes, and each will give you something you can use within your project organization as well as a sense of how the topic connects with other topics. So you can be confident you won't be left behind as project technologies roll back project complexity inch by inch. There's a lot out there swirling around project's systems and complexity. We go wherever the fastest, deepest currents are.
[00:24:24] There are ideas of power laws and scaling, of narrative and sensemaking, criticality and phase transitions. There are the dynamics of control systems and the system dynamics of businesses, ideas of agency and autopoiesis, recursion and self-similarity, but we'll keep it simple where it is simple.
[00:24:47] Sometimes when you peel back the hype, there is just good old-fashioned mechanics engineering and system engineering. Sometimes it's just defining a system boundary and articulating an interface. Sometimes, and this one is for the engineers, is just a differential equation with a boundary conditions and some of the complexity hype are echoes of deeper ideas from all the traditions and we will try to call those out too because if you know the origin story without the hype you will be able to use the original intuition without getting bogged down in fantastical language. To make progress on a complex project, we don't need to be the expert, but we need to know which expert to call in for what. Be the intelligent client asking only for the possible and limiting the cost. So we aren't the greater fools. Let me end with a story I heard about surviving with complexity.
[00:25:42] Complexity is like a lake high in the mountains, and as we climb up to it, we meet stream after stream tumbling down from that high lake. Those streams are like the bits of complexity that we break off and understand each one a topic. Once you understand each stream fully, that bit is not complex anymore.
[00:26:02] There's an explanation, a reason. But you have to keep climbing up to that higher lake passing stream after stream. The complexity is still up there that you don't understand at all. And when you are up there, finally, gasping at the deep wild lake, you must do two things, and just two things. One, you must remember that you will never understand the whole lake, although you can always understand the streams which fall away beneath you.
[00:26:33] Two, you must learn to live sometimes beside that deep wild lake without understanding it. And that is where complexity practitioners can help you. They're like the people that live alongside the lake. People like Dave Snowden or Gregory Bateson, Nassim Taleb or Michael Levin. And like those who work at the Santa Fe Institute. I hope you can join me as I continue this exploration on this podcast. Thank you for listening.
[00:27:02] That's it for this episode of Navigating Major Programmes. I hope you found today's conversation as informative or provoking as I did. If you enjoyed this conversation, please consider subscribing and leaving a review. I would also like to personally invite you to continue the conversation by joining me on my personal LinkedIn @ Riccardo Cosentino. Listening to the next episode, we will continue to explore the latest trends and challenges in major programme management.
[00:27:33] Our next in-depth conversation promises to continue to dive into topics such as leadership risk management, and the impact of emerging technology in infrastructure. It's a conversation you're not going to want to miss. Thanks for listening to Navigating Major Programmes and I look forward to keeping the conversation going.