The Physics of Project Acceleration Course

[00:00.1]
So this is a short video that summarizes, in my words, the entire book. So this is a book that essentially says that acceleration is mathematical. It’s not some theoretical concept of, contracts law, and it’s not some social agreement between people.

[00:20.3]
It’s a very, very defined thing that we measure in the natural world and equally in projects it’s a very, very defined thing that is mathematical in nature. Because it’s mathematical in nature, we separate things that will accelerate our projects from how we achieve that acceleration.

[00:40.0]
Those are two different questions. And it’s flipping those things on its head compared to how people normally approach this subject. They’ll normally approach this subject around practicality of what can we do? And then they’ll measure if it accelerates. I’m saying, no, there are things that accelerate.

[00:57.1]
Then let’s think about practicalities. Now diving in that the first part of the book is about saying what acceleration is in physics and then saying what it is in projects. In projects, it’s a little bit more convoluted because we can mean different things.

[01:12.4]
And fundamentally we talk about the eight types of acceleration. And there are eight types of acceleration because there are three variables of two. So two times two is four, times two is eight. And those three elements of variation, are: Are we looking at specific defined milestones, or are we looking at general productivity?

[01:34.3]
Are we looking at a, specific path to an activity or wider productivity that leads up? And are we looking at a fixed world view so nothing ever changes, nothing ever wobbles, or a world where things wobble?

[01:52.2]
Based on each of those eight types, you’ll have eight different ways of measuring them, all the way from an S-Curve to a P -Curve, which is associated with QRAs that kind of pockets up what it is. Then we go into acceleration. I define the acceleration equation for projects, which really is just me grouping the maths that determine how schedules work in the critical path method.

[02:18.4]
And then I break out four key framework areas, which is path crashing, uncertainty control, risk control, and system information, which summarize, all of the 33 techniques of acceleration. Path crashing is by far the simplest.

[02:35.1]
System information is probably the second simplest, though it gets pretty complicated if you want to get into productivity of people and machinery. And then uncertainty control and risk control are definitely the most complicated, but they’re also where, the vast majority of opportunity lies, in my experience, in the biggest number of projects.

[02:56.1]
Once we’ve actually talked about all of the different acceleration techniques, and I give recommendations about how you would execute these in a project. I then finish up talking about the practicalities. There’s a huge amount of potential, pitfalls that one can go through, as a senior manager trying to deploy what is to an extent theoretical thinking into a practical business application.

[03:23.1]
But the last chapter is there to address it and really it covers baseline, and change management, which is critical to doing all of this. How to think about this in different stages of project delivery, the level of analysis, some thinking in reverse, which is more a philosophy or a framework of thinking for the senior management, missing KPIs to track on projects, the concept of predictability, teams and processes and how to take this capability and then effectively execute it, in the capability framework of people, processes and systems and tools.

[03:59.0]
And then I just finish up the book with some views on the future. My big takeaway from this, or what I would heavily recommend, is read it not just for the knowledge and the viewpoints about how we address projects, but read it for the framework with which I take to address the problem.

[04:23.1]
And this is not a framework that I’ve created. This is what I’ve learned from people far greater than myself. It’s how to approach a complicated subject in a logical way of thinking, where I can take a different contrarian view about the world.

[04:42.2]
So, for example, project acceleration is mathematical, not practical. That is a contrarian view. And then how I take that and then just analyze it down and create frameworks to compartmentalize the thinking.

[04:57.9]
That means that approaching the individual problems is much simpler. So with that I’d say please give it a, good thorough chance. Even my mum, who has never been in projects, read through it and understood it.

[05:13.9]
So there’s your first challenge. See if you can understand it more than my mother.

[00:00.0]
So bullet points on the too long didn’t read the book for other people in the team or other people in the organization. Number one is that there’s an absolute science to accelerating projects. Number two most people have no clue what that science is and are not trained on it because most of the well the governing bodies do not currently teach this kind of education.

[00:21.8]
Number three is there’s a process to this and it is deployable by almost anyone that can set up a team consisting of some people who are mathematically trained who can do some sums and some people who are practically trained who can implement actions and decide if things are practically doable.

[00:40.9]
And number four is that the kind of thinking that goes into this can actually ripple across lots of other things in the projects world like contracts, management, predictability and even grand project strategy which keep hold of that term for another time. Let’s see if I write a second book.

[00:00.2]
Hi. So now we’re going to talk about acceleration and physics, and this is going to be quite, a short but fun video, actually. So, acceleration is a very, very defined thing in physics. You can’t misinterpret it because it’s described by mathematical equations. But put very simply, it’s the rate of change of velocity, and velocity is just speed with a direction.

[00:20.9]
So, keeping it simple, it’s just the rate of change of speed, and speed is obviously the time it takes you to cover a distance. So it’s the rate of change at, which you can cover a distance. You know, it’s not the most complicated concept in the world.

[00:37.5]
The interesting things are actually the equations that surround acceleration. So in physics, you might have heard of the famous equation F=ma, which is a Newtonian equation, which is force equals mass times acceleration, or rearranged acceleration equals force divided by mass.

[00:57.7]
Now, what that equation essentially tells us is that if you have mass, you can’t have infinite acceleration. To have infinite acceleration, you would need to have infinite force, which is more energy than the entire universe has within it.

[01:15.1]
Which is why if you suddenly started moving with infinite acceleration, you’d pretty much obliterate the entire universe. So if you have mass, you can’t have infinite acceleration. And equally the opposite, if you don’t have mass, if you have zero mass now, you can’t divide something by zero because you get infinity, you get a wrong equation.

[01:35.3]
So, essentially, what happens is that particles like light that don’t have any mass, or more specifically, don’t tie themselves to the Higgs field. The Higgs field is the field that gives you, in quantum mechanics, that gives you mass. You have to move at, the speed of light.

[01:51.4]
And acceleration, when you don’t have any mass, is actually just the color. So if you give something more energy, its colour changes. But you can’t actually make light to go faster and you can’t actually make it go slower.

[02:08.3]
All things being equal, you can bend space, which makes it look like light is going slower, but it isn’t. It’s always going at the same speed. So, really, in, physics there, it’s, if you have mass, you can’t have infinite acceleration. And acceleration takes energy and force.

[02:23.7]
If you don’t have mass, you have to move at the speed of light. You can’t stand still and you can’t do anything else. Now, the two key things here that we need to take away is, with things that have mass, which is really all we’re going to talk about, because acceleration can’t be infinite.

[02:43.1]
You get curves. So if you, if you had a graph of how you’re covering distance over time, you know, if I’m standing still and then I slowly go up to a run, I have a swoop. And then if I start to get to the finish line, so I start to slow down, I have a reverse swoop, I produce S-Curves.

[03:02.9]
So acceleration and deceleration produce S-Curves. And if you’re familiar with S-Curves in project management, you can see where we’re going to start going with here. Just as an aside, I had a very good conversation with a friend of mine who runs some projects over in Saudi right now.

[03:20.0]
And, he asked me the very interesting question, well, can the laws of entropy and inertia in physics be applied to projects? Possibly. You know, we’re using a context switch and, you know, thinking from this area to see how we can think differently about this area.

[03:40.3]
But I’ll leave that with you to maybe Google and have a think about, if you’re interested.

[00:00.1]
So now we’re going to get onto the real meat of talking about acceleration in projects. Now, from the last video, we talked about acceleration really being about swoops on graphs. It’s about the speeding up of velocity or the change of velocity over time, both in the positive and negative direction, which is acceleration and, deceleration.

[00:22.5]
Now, this is where we need to revert back to the, the first video that I recorded about the main premise of the book, which is we’ve used a substitution. We can’t predict how the world works and we can’t have a relative comparison for projects. So instead we’ve substituted the problem of perfectly accelerating the real world with accelerating a model that we’ve developed, which is based on the critical path method and is the schedule that we think represents the real world.

[00:50.9]
So what we’re going to do is we’re going to mess with our, schedules and, we’re going to measure acceleration by whether or not it changes graphs. Now, if we take a simple graph like an S-Curve, then if our baseline is like that and we manage to go steeper, so the swoop goes faster and we stay above that line and we decelerate earlier and sharper, you and I would talk that we’ve accelerated that project.

[01:21.5]
Equally, if the swoop takes longer and the main gradient is less, so we’re falling behind and the deceleration takes longer, we’ll say that the project is delayed. All of those are acceleration and deceleration. Now, if we’re standing on ceremony, technically acceleration is only when you have swoops.

[01:42.7]
So a positive swoop, or a negative swoop, it’s not where you have any straight lines. This is where I’ve decided to take a more generalist approach, because either we can be exactly right and not useful to anyone, or we can bend the rules a little bit and try and be as useful as possible.

[02:02.4]
So I’ve just said anything where lines are above baselines in, for example, an S-Curve, we’re winning. That’s acceleration. And anything where lines are below baselines, we’ll call it deceleration. But we live in the world of projects and we have other things to consider within this model of the world that we call a schedule.

[02:24.5]
And those other things are, dependencies. So tasks with relationships with other tasks and milestones, which determines how we get to our, finish point. And variability. Variability is simply that nothing ever goes to plan.

[02:40.2]
Things wobble, and we can’t perfectly predict everything. Now, on the first, the dependencies, dependencies determine which productivity matters. So for example, if you said to me, greg, I want to accelerate getting to this milestone here, and there’s activities linked to that milestone, and there’s activities not linked to that milestone because they’re linked to something else, then only the first set of activities actually matter in accelerating here.

[03:11.8]
All of these things not linked don’t matter. So dependencies determine which things matter for which acceleration you pick. Variability is a little more complex because variability determines which scenarios matter.

[03:30.0]
So for example, if you said, I want to accelerate this milestone and I want what’s known as the P80 position or the probability under all scenarios that we hit this date, or earlier, 80% of the time, very specific, I want that to be left.

[03:55.3]
The variability that you input will determine which is the 80 and which is the remaining 20. A little bit complicated, but, I’ll try and simplify it later on. So if we combine the thing we’re targeting. So is it a milestone? Is it just general productivity?

[04:12.8]
Is it multiple milestones? And that’s number one. Number two, if we talk about how we’re getting there, so is it every single path we can get there, or is it just, for example, the critical path? And then the third one is the scenarios.

[04:30.2]
So are we considering this route, this world, just as deterministic and fixed and just saying that’s it, or are we saying that things wobble? So under some situations this is the critical path, but under other situations, something else is the critical path.

[04:45.7]
You have three variables there. Now those three variables I’ve simplified down just to having two choices. So, in terms of targets, you can choose one, milestone or target, or many milestones or targets.

[05:02.5]
In terms of path, you can choose just the critical path, or you can choose everything in between. And number three is, just fixed world. So no variability or you’re including variability and 2 x 2 = 4 and x 2 = 8.

[05:22.0]
So you actually get eight different types of project acceleration just as a bundle. So I’ve called these the naming convention matches how you’re choosing those. So you’ve got: Fixed General Productivity Fixed Critical Path Fix Many Paths Fix Filtered Productivity And then you’ve got: Variable General Productivity Variable Critical Path Variable Many Paths Variable Filtered Productivity I’ve got graphs and things.

[05:51.2]
To be honest, I’d just say stick, a sticky note in the book when you need to refer back to these and just look at the table on which ones you pick and which ones it means. Even I don’t try and remember these because remembering something is not understanding something. Now, the final point in this is that the different methods, you will use different graphs to measure if you’ve achieved something, if you’ve achieved acceleration.

[06:19.8]
So if I flip to, all of these methods are on, page 26, within the book. But if I flip to, page 30, you’ve got the table that has all of these different methods.

[06:37.7]
And I’ll give you an example. So in Fixed General Productivity, we’re not considering variability at all. So just ignore all the wobble. And all we’re thinking is General Productivity is every single milestone with every single path.

[06:54.0]
So I’m just trying to be as productive as possible. Really, what I’m trying to do is just maximize utilization of people. Every day as much work gets done, no matter if it’s on a critical or subcritical path. Now, the way you measure that is with generally an S-Curve because an S-Curve is just curve of work.

[07:14.3]
It’s just the total work. Now, you could completely ignore the critical path, but as long as your S-Curve is just measuring work, it’ll still go up. So you’d look on the S-Curve that the, productivity curve you’re producing is above it.

[07:31.4]
That’s acceleration. Now, if we take a different scenario, so a completely opposite scenario, so Variable Critical Path, where you are considering variability, you’re only looking at the end milestone, and you’re only considering the critical path to that.

[07:50.2]
That’s very different. You measure that with what’s known as a P-Curve, which is a probability curve. It looks like an S-Curve, but it is actually measuring different things very similarly, though. Well, you’d pick a P position, but the steeper that is, and the more left everything is, the more acceleration.

[08:11.1]
But here’s the key thing. You cannot measure the first with a P-Curve, and you cannot measure the second with an S-Curve. So you have to pick which way you’re measuring it. It’s the equivalent of saying, I’m going to measure mass with a stopwatch. It’s like, but mass isn’t a time thing.

[08:28.1]
You need some kind of scales. Or the reverse is, I’m going to measure time with a weigh scale. It’s like, no, that’s not how these things work. It’s the same here. They’re all different things. You need to measure them a different way.

[08:43.8]
And I just flip to the book when you need to refer to how you measure which one.

[00:00.5]
Okay, so we’re able to pick what kind of acceleration we’re trying to get. To be honest, thinking about it, I maybe should have just called them colors, but you can’t. That makes it even more complicated. But let’s just for simplicity, in this video, say, you know, we pick red acceleration rather than green or purple or yellow.

[00:20.6]
If that element of the book is like big value point number one or you know, different way of thinking about the world, then this next one is big value point number two, which is what I’ve called The Acceleration Equation.

[00:37.1]
Now The Acceleration Equation is everything mathematical that influences those curves within the schedules that are based on the critical path methodology. Remember, schedules under critical path methodology are mathematical things that humans have invented.

[00:57.1]
So it’s that substitution, it’s those. And it’s actually very simple. You’ve got the information about the bits, the things which are the tasks and the milestones. So if I was to do a Gantt chart, I’m going to sprinkle on things that sit there.

[01:16.5]
Then I’ve got the information on how those things are connected, which is the dependencies or the interconnections. Then there’s the information about how all of those things wobble. Because we live in a world of volatility and wobbling isn’t just things like task duration.

[01:36.8]
It can actually be the existence of those things, which is scope change. So if I measure a project at the start and let’s say that I’ve done the most detailed schedule that I needed to, and it’s a thousand things, and then I measure it at the end and I’ve got two thousand things and the thousand thing is genuinely scope change, then that is actually massive variability.

[01:59.2]
So it goes under that. And the fourth thing is kind of the most, it’s not the most obvious, but it’s the thing about relativity. So it’s system information, which is the rules that you’ve rolled out of the back of this thing that you call a schedule.

[02:19.1]
And the rules are things like constraints and calendars. So if I say we’re working a seven day week, there’s no days off, the schedule will behave differently than if I said, except for those people over there, they get three days of work a week and four days off.

[02:39.2]
That fundamentally changes if someone, some delay happens, how the thing ripples on down the line. This is a massive problem, by the way, or a challenge in railway possessions or possessions of time constrained assets. So this Acceleration Equation just contains those four things.

[03:00.2]
So it’s the mathematical pieces that make up schedules. So it’s tasks, relationships, variability. Everyone forgets that one system information, which is the map that you’ve based it on. But these four things are kind of esoteric, which is a word that means you can’t really relate to them in real life.

[03:21.7]
If you’re thinking about acceleration, I can’t go, how can I accelerate relationships? That’s just, that’s just a silly thing to say. So what I did is I mixed them up in ways where we can do that, and I created four buckets, of techniques.

[03:41.2]
So the buckets of techniques, which is what the majority of the book goes through, which is the recipe of how you actually accelerate, I’ve combined Task Information and Relationship Structures into something called Path Crashing. Because if you’ve got tasks, and if you’ve got relationships that link tasks together, you have paths.

[04:02.1]
So we can accelerate by crashing paths, either by things like shrinking activities, changing dependencies, removing activities, removing dependencies. You see how that plays out. Then Variability Factors, I’ve split that into two, primarily because different people deal with different things.

[04:23.8]
So Variability Factors is all about Uncertainty, it’s all about wobble. But we can have scheduling wobble, which, is associated with things like task duration. And we can have Risk Events.

[04:42.6]
Now, Risk Events is wobble. But a risk event normally touches many activities and has different effects on it, such as it extends activities, it adds activities, it does complex things to it. Those are normally dealt with by risk managers.

[04:59.9]
So I’ve just split those out. They share a lot of techniques. But how you actually go to accelerate changes depending on which one of those you use because of the effects of risk events and the grouping. And then I’ve kept System Information the way it is because it’s a simple thing in its end.

[05:17.4]
We can go, how do we accelerate? By changing the rules with which we’ve based the schedule on is a valid statement to say. So with those two, we get to the kind of final equation, which is acceleration is proportional to the grouping function of Path Crashing Uncertainty Control Risk Control System Information And that now makes up, pretty much the rest of the entire book.

[05:43.7]
Under each of those, there’s different techniques. So under Path Crashing, if my memory serves right, there’s six techniques, Uncertainty and RIsk Control, there’s about 10 to 12 each. And System Information, there’s three to four techniques. But we can, we can now just go to those and go, right, I want to, under Path Crashing, do exactly this.

[06:04.2]
The final thing that I’d say is each of these techniques. So Path Crashing, Uncertainty Control, Risk Control and System Information, they affect the eight types of acceleration differently. So for example, if you’re doing a, fixed world acceleration type, so you’re not considering variability, then uncertainty control and risk control have absolutely no effect on your project, zero effect at all.

[06:33.4]
So you might as well just not even think about them. If you’re doing a project that does consider variability, they are actually likely to have the biggest impact on the entire project. Because in my experience, and from the data that we’ve seen, most projects suffer from extreme volatility.

[06:53.2]
That’s one of the things that drives deceleration or delay in these projects. So each of the techniques going forward works differently based on which acceleration type. But zooming out, the way to think about this is this is just a cookbook.

[07:11.9]
You know, you’re deciding whether or not you want a fish dish or a chicken dish, which is the type of acceleration. And then, you know, it’d be silly to throw fish in a chicken dish because it wouldn’t be a chicken dish at that point, which is. Okay, well, you wouldn’t use that technique for that one.

[07:29.1]
You see how I’m getting at this. It’s just purely a cookbook. The certain ones that work really well together, the certain ones that kind of work well with everything, and the certain ones that absolutely do not go together. And that’s really the key part.

[00:00.0]
So path crashing – the first of our four acceleration buckets of techniques. Path crashing is by far the simplest technique, and it’s the one that, to be honest, everyone should be able just to get their head around, even if you didn’t have a project management experience.

[00:17.1]
Path crashing, as you can see on page 54, it’s very useful for anything that involves paths. It’s less useful for things that involve multiple paths or general productivity ones, because by the very name, it’s about making certain paths shorter, not about focusing on reducing variability or increasing utilization generally across the project.

[00:42.0]
Now, under path crashing, there’s six techniques. And I want you to imagine in your mind’s eye now just a single path, just an activity, an activity, an activity and a milestone. It’s like, okay, what can we do to that to make the milestone go faster, to bring things to the left?

[01:02.0]
Okay, well, very simple. If there’s a lot of flow, we can literally just move things. This is the first one. It’s milestone and task movement. The second one is we could shrink the duration of the activities so that it can compress on almost a little bit, like pushing on a cushion.

[01:19.0]
It just gets smaller. The third thing we can do is actually just take one of those activities and throw it away, because if we actually don’t need to do that scope of work, then we can get rid of it and move everything closer together too. The fourth one is a link type change or a dependency change.

[01:37.2]
So, for example, in this, let me go back one step. There are different kinds of links that you can have within this model that we’ve called the schedule. One of them is called a Finish-Start relationship, which means that you have to finish this thing before you start this thing.

[01:54.3]
It’s a rule. So you can’t go before it’s solid. Another one is a Start-Start relationship, which means that you can go left and you can start this once you’ve started that. Now, the barrier’s here, you can’t do that, but you can see how this enables us to move these activities and create an element of parallelism.

[02:15.3]
If you’re able to change, for example, a Finish-Start to a Start-Start or a Mid-Start or something else, you can compress it and move everything shorter. Number five is path switching.

[02:30.9]
Now, path switching is – imagine in your head now you’ve got two paths, and one has free space in it. Can you actually move activities by changing their dependencies from one path to another? Overall, you shorten everything, even though you’ve elongated one, but you’ve shrunk another.

[02:53.0]
So, for example, if you’ve got one that’s that big and one that’s that big, can you just balance them like that. So everything goes a bit faster. An example of this is in things like, pipe bending offices, which are on the project site, but actually much more like production lines.

[03:15.1]
So it’s like if you’ve got two pipe bending offices, one is absolutely maxed out and one, they’ve got no work and they’re just sitting around. Can you shift work over here so that both of them are working productively? And then parallelism is the opposite of this, which is you don’t have two paths, you only have one path.

[03:37.1]
But it’s thinking, okay, can I actually split that into two paths and have them doing this way? Which brings everything shorter. And an idea of that is, for example, going, well, I have to have the electricians in before the plasterers or something like that, saying, okay, they have to follow that way.

[03:59.5]
Well, it’s going well, actually. Are, there a bunch of rooms where I can do elements of the plastering, then sending the electricians, then finish it off, versus having this linear line going along? So that’s really about taking one path and being able to split it into many paths to bring it down.

[04:21.9]
And it’s essentially just enabling lots of people to work generally at the same time, as opposed to waiting for each other to finish jobs. And those are the six techniques within path crashing.

[00:00.5]
So Uncertainty Control. This is probably the deepest thinking I actually did, going into this book. I actually think this chapter probably took 50% of the effort and time on understanding project acceleration because by its very nature, it’s kind of counterintuitive because it’s to do with statistics and the maths associated in part with gambling, which doesn’t come naturally.

[00:30.9]
But we can dive into it. This will be a bit longer of a video. I’m not going to cover all points, but I will say that give this chapter a good read because there’s some fundamental principles in there, that will help you understand how projects behave better than quite a lot of others.

[00:49.0]
So to start with, you’ll see now we’re getting into a bit of a formula for how I’ve addressed these different techniques. First of all, I explain which of the eight types of project acceleration they’re associated with. Then I give a description about what the technique is.

[01:04.9]
And then we actually go through all of the different layers of techniques within. Now, in uncertainty control, there’s 10. Now, uncertainty control. So let’s ignore an entire project now. Let’s just focus on a single group of activities.

[01:22.9]
So let’s say we’ve got 10 activities. There’s two numbers we care about here, which is the average time it takes to do a repetitive activity and the range. Now we can take this up to the size of the project.

[01:41.3]
What’s the average productivity and what’s the range of productivity within this and at all levels. And it’s really those two numbers and the shape of the graph that we’re manipulating here. There’s two things we need to know before I dive into the 10 types of uncertainty acceleration.

[02:02.5]
Number one is that, a lot of inspiration from this area came from my, study of quantum mechanics around the Heisenberg Uncertainty Principle. And the Heisenberg Uncertainty Principle states that you can’t perfectly know location and momentum or energy of a quantum particle.

[02:26.9]
The universe just doesn’t allow it. There’s no such thing as a solid atom, and there’s no such thing as a stationary thing. Everything moves with uncertainty. So what it essentially says is the more precisely you try and figure out where an electron is, the wilder its energy goes all over the place, its momentum, so it moves.

[02:52.3]
Equally, the more you precisely you trying to measure how much energy something has, the more it disappears. All over the universe, it just flies off and goes all over. There’s a limit by which you physically cannot make the universe be more certain.

[03:09.8]
And actually the same kind of principle can apply to projects in terms of variability and base speed. Now base speed, what I mean is the deterministic critical path.

[03:26.2]
So if I want the deterministic critical path to be as squashed as possible so I have no float at all, then variability is going to cause massive delays when you do simulations because even a second of things taking longer will push the critical path.

[03:45.7]
It’s super sensitive. But conversely if you stretch that critical path so you’ve got float within it, so it’s not really a critical path, it’s a longest path, then variability gets hidden within the float within that path.

[04:02.1]
So you can actually have a decent amount of variability before the path changes. And this is just an iron law of projects really, or the projects universe, which is unless you have absolute zero variability, which we can’t have, the more you try to compress a project in its critical path, the more you’re going to blow out the project on the simulations when you consider variability and conversely when you stretch the path, you’re going to lower how much the project is affected by variability.

[04:41.7]
So that’s the uncertainty principle. The second one is what a typical distribution of behavior looks like, either at a task level or a project level. And put very simply, it’s a bell shaped curve with a really long tail.

[04:58.7]
So what I mean by that is the highest point of the bell is the average. The average is your average productivity. It’s generally, you know, in the data we’ve seen, it’s generally actually close-ish to where you wanted it to be.

[05:16.0]
You can go faster, which is why there’s a bit on this side of the bell. And you can go longer, but you can also go much, much, much, much, much longer. And by the rules of unfairness in the universe, you can go infinitely longer, but you can’t go infinitely shorter.

[05:36.0]
So if a task takes five days, you can’t do the task in minus infinity days because we can’t go backwards in time. You can only do it up to zero. So you can accelerate by five days, but you can go from five days to 5,000.

[05:54.9]
That is totally possible. It’s just unfairness. And this statistical, distribution causes unfairness in that the actual average starts to migrate because this long tail pulls it out.

[06:11.6]
It’s just an unfair principle of the universe. Okay, so I want you to have that picture in the mind that we’ve got this distribution that’s a bell with a long tail. Now because the way we accelerate Is we play with the maths of the model that we use to simulate the world, which is the schedule.

[06:30.7]
We’re going to just play with that graph. And that’s where the 10 techniques come in. So technique number one, productivity alignment, which is if that’s your base productivity and that’s what you’re actually delivering, you just do everything to move that left, everything you possibly can.

[06:48.2]
And I name a lot of techniques you can use to pull it left in the book. Now, this is not like path crashing, where you just shrink things or move things because of that distribution. I can move things left and cause things to balloon that long tail.

[07:06.9]
I can move things left and destroy any acceleration potential I have. Beyond that, I can move things left and then actually shrink and make the whole project better. And a lot of different options. But really principle number one is just focus on one thing, just move that left.

[07:26.4]
Equally, I can do the other thing, which is I can try and shrink the distribution, the bell. The width of the bell is called the distribution. So I can just try and shrink that. So it’s a spike. Because if I shrink that, I actually gain more certainty.

[07:44.6]
And arguably I kill a lot of the scenarios in the long tail. They’ll still exist, by the way, but I just tried to shrink that. Now I could shrink it by moving the productivity even worse. But I’m getting more certainty, which means in a number of scenarios, I’m actually going faster.

[08:01.5]
You see how this is counterintuitive? I can go slower but go faster at the same time, dependent on how the dice land when I roll them. Number three is just taking an axe and slicing the long tail off. Now, it’s very hard to slice the long tail off.

[08:19.7]
What you’d practically do is you’d run risk and you’d run, simulations like Monte Carlo analysis. You’d figure out through your tornado graphs what is causing the long tail. And then you’d send your project managers, schedulers and risk managers with an enormous budget and say, make those go away.

[08:38.9]
And that’s through risk action or replanning or, increasing capacity or whatever. There’s a lot of techniques that you can use to do that, but you’re trying to shrink that long tail. Because if I’ve got this distribution with the long tail and I shrink that in, there’s less scenarios where I go really late.

[08:59.8]
So on average I will be faster. The fourth technique is literally the opposite of it, which is to create opportunity. Really, it’s to create reverse long tails. So the bell does that. What we’re going to do is try and give opportunities for teams to go much faster.

[09:17.9]
So not five days, one day. Number five is about change control. And this really comes back to a key principle I talked about at the start, which is uncertainty and variability doesn’t just look at the things that exist today.

[09:36.5]
So when you start your project, it also concerns the things that could exist in the future, which is scope change. So change control is about putting principles and policies in place that massively, control what change can happen to the project.

[09:56.2]
Because if you’ve got a project or a set of projects that have historically really suffered from change and you eliminate that, the chances are, you will accelerate your delivery compared to things you’ve done in the past. Relationship confirmation is the volatility associated with relationships.

[10:17.7]
So I call it confirmation because it’s really going in and asking the question, is this really the relationship associated with this work or can we think of a way to do this better? So you’re confirming what is really true as opposed to relationships.

[10:35.4]
Just varying task duration can vary for a number of reasons. You know, rain, people are just not feeling well, etc. Relationships can’t just vary for a number of reasons. It can’t just be random that building the second floor is suddenly not associated with building the ground floor or the foundation.

[10:56.4]
It doesn’t work like that. But you can confirm what they actually are. And the more you confirm and bring certainty, so less uncertainty and volatility, you can accelerate the project. Impact avoidance is the extreme form of, long tail slicing.

[11:15.7]
And essentially it’s about cutting scope, just taking a knife to the scope that you’ve got to do and removing all of the scope that creates the long tails. Incredibly hard to do. Because quite a lot of projects are very interconnected, but there are opportunities.

[11:36.2]
In quite a few projects that I’ve seen, the long tail is driven by a core piece of, for example, design work that’s completely uncertain in its design. And what you can do is go, no, this project only considers this and we’ll create a new project separate to that, with new contracts that considers that because they’re different forms of risk.

[11:59.1]
And this is actually one of the key things I say in the chapters, which is one of the biggest things that creates uncertainty in projects is infecting projects with types of risk or uncertainty that they’re not designed to deal with.

[12:16.4]
An example of that is if you’ve built a project to be as productive as possible, throwing in design change is not aligned with being really productive. It’s designed for, for massive iteration of design and learning. Not being productive.

[12:38.7]
The next one is uncertainty measurements. And this is you might think that this is a little bit of a cheating one. But it isn’t because again, our job is to change those curves. And if we change curves, we accelerate the projects by actually just measuring what the project is producing.

[12:58.6]
We replace the assumptions we had at the start on how volatile the project is with reality on how volatile the project is. Now it could be that the project is less volatile, at which point we’ve immediately accelerated. It also could be that the project is more volatile, at which point we have negatively accelerated, which is deceleration.

[13:21.2]
But it is still acceleration of some kind of decomplexifying is a really fun one. There’s a lot of, there’s a lot of complex science that goes into it, but long and short it tries to explain second and third order effects that happen in projects.

[13:43.6]
And it’s all of the sub networks. So we’ve said we’re manipulating this model that we think represents reality, which is a schedule. But there’s lots of sub networks that sit under the schedule that connect things that aren’t connected in the schedule.

[13:59.1]
For example, labor relationships. So a welder can do task A and then have to go on and do task Z. And A and Z are not linked in the schedule. So it deals with the fact that you’ve got hidden links in the schedule to reduce the uncertainty of how the schedule behaves.

[14:21.4]
And the final technique is the pull and button technique which is actually very associated with operations, management and production lines. So it’s actually much, much faster if you’re building cars on a production line to stop the entire production line to fix an issue than, than it is to try and take the car off or change that production line in how it’s working because it’s so geared to be productive in one direction.

[14:54.0]
The pull and button is, if you start seeing uncertainty balloon beyond a certain amount, just stop the entire project before that uncertainty cascades and completely gets out of control with all the different suppliers and labor, laborers and permits, etc.

[15:14.0]
The final thing I’d like to say about this section is I make a point within impact avoidance about risk adverseness. Now what I say in, in it is that impact avoidance is not about being risk adverse.

[15:30.3]
It’s about avoiding meaningful speculation about the future. And the reason I want to draw attention to this is that when we look at the volatility or the variability around project schedules, the vast majority of projects I’ve looked at speculate.

[15:50.3]
They speculate about what the future might be. Now I said, avoiding meaningful speculation. So it is totally fine to speculate so long as it’s not meaningful as long as it doesn’t really matter to the results.

[16:07.5]
But if you’ve got something that really, really drives the speed or the acceleration and deceleration of your project, you cannot speculate about what that is. You need evidence to drive what you think that is.

[16:23.4]
Now, giving you an exact example of where I don’t see this happening in projects is where teams have to do Monte Carlo simulations and they just pick plus 10, minus 5% out of the air without going back into previous work and measuring so uncertainty measurements, what they’ve actually produced in the past that massively drives results which massively affects acceleration and deceleration.

[16:49.9]
And it’s completely speculation. So I just say please avoid meaningful speculation when you go about doing uncertainty acceleration.

[00:00.5]
Okay, so now we’re moving on to, risk control. Now, risk control is a very interesting one. If we’re looking at, the physics of acceleration purely through a mathematical lens, risk control wouldn’t exist because risk control is just a subset of uncertainty.

[00:21.3]
Fundamentally we’ve got task information and relationship structures, which make path crashing. We’ve got uncertainty control, and then we’ve got system information and we’ve just broken uncertainty control out. Now a key thing to start with here is that, what is risk and uncertainty in other places in the world?

[00:45.6]
So in physics, risk and uncertainty is around your measurement of results. It’s about the volatility or the variability that results can take. So if I said this is exactly 2, risk is plus or minus this.

[01:05.4]
Now risk can also be plus or minus a great deal, and it could also be weirdly shaped. So it’s generally this, but maybe sometimes there’s a blip over here. But generally risk is about not being the answer that you want it to be or the average or whatever.

[01:26.2]
This also follows through in the investment landscape. So when, people actually talk about, the risk of stocks or the correlation of stocks, what they’re talking about the risk of stocks is the volatility of the share price.

[01:42.2]
So if a stock has a very high risk associated with it, then there’s a lot of uncertainty about what its stock price in the future may be. And this, this applies both to stocks and to options. So in stocks they talk about something called alpha and beta correlation.

[02:02.3]
Alpha, correlation is not being correlated with the bucket of other stocks that you’ve got with it. So if something has extreme alpha, it means that it is an outlier. And that is generally what private equity are trying to find.

[02:20.5]
Beta is the overall movement of the landscape. That’s, to be honest, what index funds are trying to achieve. So venture capitalists and private equity investors are trying to achieve alpha uncertainty. And then index funds are trying to achieve correlation or minimize risk with beta uncertainty by buying everything.

[02:45.2]
In the options world, they, they use something or they used to use something. It got the Nobel Prize for economics called the Black-Scholes Model, which was how to price options in the future. And a large part of pricing options was the volatility of the underlying stock. So very interesting.

[03:01.9]
What I’m trying to say here is that in many industries, so banking, investments, healthcare, physics, risk is uncertainty. It is volatility of what the result will be, and it is highly mathematical.

[03:22.9]
It is the absolute core of it. Projects are no different. It’s just that, we haven’t really generally taken maths and risk experts from healthcare or from insurance or from banking and parachuted them into project management roles.

[03:43.2]
But let’s be very specific about what risk control is here. Well, risk control is just a subset of uncertainty control. It’s just a different way of slicing the world. If we’ve made this substitution from the real world to a model that we’ve built around the world, which is the schedule and now the risk register.

[04:04.9]
Each thing in it has curves and the overall model has a curve. In physics, the great things about curves is that they’re just summations of more, elementary curves.

[04:21.9]
So if I had a curve that did that and a curve that, the way that you combine the curves is you literally just add them together and you get the letter M. Risk control is that. So if you’ve got a distribution like that, the risk might be this blob, there and other uncertainty might be this and they’re just added together.

[04:42.2]
So the question then, which comes full circle, from a physicist, they’d be saying, why are you separating out risks, as if there’s something uniquely special compared to uncertainty. And I said okay, for three reasons really. Number one is the concept of a risk event.

[05:01.9]
So a risk event is something like there is a risk it may rain on Tuesday and that would affect many activities. Every rain susceptible activity on a Tuesday is affected by that. So there’s actually a network risk network that has tentacles into the scheduling network.

[05:22.3]
And that matters for the mathematics of it. Number two is that these risks can just be separated from the general uncertainty distributions because of maths. So you can take them out and have them as a separate component and then you just have to add them together.

[05:41.5]
And the third element is, that they’re managed differently. So the general uncertainty can be looked at, but for example by project managers and schedulers and planners. But risk events in some situations are managed by risk managers.

[06:04.2]
So an actual profession in a risk register, which is a separate asset to the schedule, etc. So it’s just that if you want to have a meaningful impact on project acceleration focusing on these risk events, I just have to fit in with the way that the world has been designed by humans here, which is to have risk registers and risk managers here as a final note as well.

[06:32.2]
And this applies to uncertainty, but it applies even more to risk events. So curves can take any shapes. You know, I could write my name as a curve if I made the equation complicated enough. But risk events are unique in that they’re much more common to be sharp edges.

[06:53.1]
So what I mean by that is it either rains or it doesn’t. And by doesn’t, what I mean is it doesn’t rain enough to stop work. Now there might be a little bit of gray area in between, but if I drew it, it’s zero impact, day impact and it’s almost immediate.

[07:13.4]
So risk can be more jarring in that way. So because risk events and risk control is just a subset of uncertainty control, a lot of the techniques actually map over.

[07:30.7]
But they map over, but they’re not perfectly identical because the difference in how they’re managed, the fact that a risk event is a different way of cutting through the world. So you can have a risk tied to many activities. So it’s a different network and the fact that they behave slightly differently in the steps.

[07:48.9]
So there’s some subtleties to it. So the 13 techniques covered in the section, one is risk specificity, which is really the principle of not being too general, so not just saying, oh, well, rain hits all 200 activities in exactly the same way.

[08:07.4]
Well, you know, it might hit activity one slightly different than it hits activity two, etc. So it’s about putting in the brain power to just be more specific. If you’re more specific, you change the curves. Changing the curves accelerates or decelerates the project.

[08:24.6]
Number two is risk evidence, which is a different flip on specificity. So this is about actually, getting evidence behind the risk that you’re saying. So rather than just saying, well, rain will have this impact, I’m saying, okay, well is there any evidence that rain would impact that, specific activity in that specific way?

[08:49.2]
Or are we just making a guess here? Three is risk inclusion, which mathematically has no impact overall, but because of the way contracts are written mathematically in that it does have an impact.

[09:04.9]
And that’s just saying, okay, well if you’ve got a risk, that’s a 90% probability, say, just include it in the scope of work. So it’s 100% and then you’ve got a 10% acceleration option. So it’s just about what you class as the baseline in that sense. Number four is insight impact isolation, which is about really if you’ve got dangerous risks that touch a section of activities to carve out that part of the project, either know with buffer or actually carve it out contractually or something different such that it has a lot less chance to infect the rest of the project with delay probability.

[09:47.2]
Minimization and impact minimization are the most common that people will understand because risk events are written in the form of there is a risk that X will happen and X will have Y impact, Z probability. If you change, you know, let’s say the impact is 10 pounds and the probability is 50%.

[10:10.8]
You know, if I times 10 pounds by 50 or $10 by 50%, I get $5. If I reduce the probability down to 10% equals to $1. If I reduce the impact from $10 to $2, I get, you know, $2 times 50% is $1.

[10:29.2]
So there’s different ways that I can reduce the disruption that a risk event puts in. Then we’ve got long tail slicing. Now long tail slicing is a little bit more nuanced here because in uncertainty control, long tail slicing is about finding out the units in the schedule, the tasks, the relationships, etc, that drive the long tail of the project.

[10:53.3]
This is about finding the risk events that are most associated with driving the long tail of the project. I say it’s a little bit more complicated because risk events can touch many activities and some of those activities can be in the bulk of the project. That’s why it’s a bit more complicated to do.

[11:10.7]
Impact avoidance is the same as uncertainty control, which is just refusing to do the scope of work, that carries with it the highest level of risk. Impact absorption is about putting strategic buffer zones in the project to such that if a risk triggers the effect, the negative effect it has on the project network is absorbed by those buffers.

[11:38.7]
This is a principle of you go slower in a number of scenarios to go faster across all scenarios. The pull and button, this comes from operations management and this is really, you have an emergency stop button.

[11:58.9]
They have these on production lines for cars. So if there’s a problem, someone can hit a button and the whole production line just stops. It’s not quite a safety switch, but it’s like a safety switch for performance. And what this pull and button is about is if a risk event triggers.

[12:17.8]
And that risk event is so insidious to everything that sits there, I don’t know what it could be. It could be, the price of concrete goes up by 10x or something like that, or tariffs get implemented that just mean that the actual cost of doing the project blows beyond the ROI that the project’s supposed to be delivering.

[12:39.1]
There’s this button that just stops all work. And then everyone’s sent home except the planning and project management team, and they figure out how they’re going to restructure the project. Opportunity creation is good risks. Risk is just volatility.

[12:55.1]
But volatility can be, you know, the stock price has increased by 50x. I’m pretty sure everyone would be happy with that, if you invested in the stock. It’s why venture capitalists invest in companies is because there’s a small chance that they can earn an enormous return on that.

[13:15.1]
So it’s about how do we create good uncertainty here? And impact reversal here is about flipping the scales through financial products or other means. That means that if a risk event triggers either it has zero impact because of what you’ve put in place, the mitigations you’ve put in place, or even it has positive impact.

[13:38.6]
And you may think to yourself, how would a risk triggering that’s negative, for example, it causes a delay have a positive impact? Well, it depends who you are and it depends on the contract that you’ve signed. I’ve seen many projects where performance is not going to plan from, for example, the general contractor, then, the client.

[14:02.8]
A risk triggers in the client organization such that, for example, materials deliveries that are required by the general contractor can’t be made on time. And then that is made the focus of all the problems. And then all of this delay gets hidden under the weeds and they’re able to catch up.

[14:22.2]
So that in this sense is someone contracting to pass the risk across the other table. There’s a lot of diagrams in this section because it’s important, to understand how these things work.

[14:37.8]
But the key thing here is just that risk management in projects is partially a social science. A large part of it is a social science because you have to go and speak to people, convince them that there might be some uncertainty associated with, the project or the activities that they’re doing.

[14:56.5]
But at the core of it is risk is mathematical. That’s what pretty much every single industry in the western world has figured out. It’s just that, for some reason, and I don’t know why projects have either figured it out or actioned it less than other industries.

[15:17.6]
I think it might be because of the regularity. So if you were creating a bank and the bank was only supposed to exist for three years and you had to build it up to 5,000 people within half a year, and then you had to kind of get those 5,000 people off the books and close the bank within six months of the third year.

[15:38.7]
I could understand why you wouldn’t invest a huge amount of money and put an incredibly long term robust risk management processes in place. But the business case of it doesn’t change the nature of it. The nature is that risk is mathematical.

[15:55.9]
And that’s what I’d like you to take from this section.

[00:01.4]
So now we come to the fourth and last area of the acceleration equation, which is system information. And I have to say, system information was actually the most fun chapter to write of this because it really, it really harked back to some of the core principles within, physics, specifically Newtonian physics and general relativity.

[00:22.1]
It’s not that complicated, but it’s really about the frame and the philosophy with which, you actually look at projects and you look at schedules and you look at the models we build. So the first part of it is we really have to think about what is the backdrop, what is the world that we build this model of the project in.

[00:43.4]
So you might think of it just simply as calendars, but it’s far more than calendars. And I’ll give you an example from physics. So when you talk about general relativity, the key thing about general relativity is that it is the fabric of space time that warps and changes.

[01:02.1]
And dependent on where you are in the universe, the fabric is different. And if you can understand how, what the shape of space time is, you can use normal equations to figure out the paths of particles and how light will change and these kinds of things.

[01:22.0]
So here on the Earth, we are generally in what’s known as a flat plane because gravity isn’t that strong. We still have a well which is going towards the Earth and a small well which is going towards the Moon. And the Earth is tidally locked to the sun.

[01:37.4]
But for all intents and purposes, we’re on a flat plane here. So space isn’t curved. It’s not like my arm is being pulled more than my head in a certain direction. And the way we model that is with what’s known as cartesian coordinates, which is X, Y and Z, or polar coordinates, which is the same, it’s just a different way.

[01:59.2]
So X, Y, and Z is up, forward and back, and side to side, polar coordinates is a direction, a distance, and then a direction up and down. It’s just different ways of explaining how to get somewhere. It’s just when you do the maths, cartesian coordinates is much more associated with linear algebra.

[02:19.3]
And polar coordinates is much more associated with sines, cosines and tangents, which makes some maths easier and some maths harder. But when you start to get near massive object like neutron stars or black holes or even, you know, if you’re zooming out and you’re looking at a solar system like ours, space starts to warp.

[02:40.6]
Now, warping spacetime, you can have lots of different shapes. You can Have a space time that’s a dip, which is a black hole, something like this. Theoretically you can have a white hole though I don’t think anyone, well, we’ve never found one.

[02:57.0]
And I don’t think anyone really believes that they exist for some reason, I don’t know why, but it’s the opposite. But you can also have ripples. Which is what? The gravitational waves that, scientists recently observed of two massive black holes colliding, they actually cause a ripple, like literally a wave in a sheet.

[03:18.1]
If you whip a sheet in space time and particles will move differently. Just as if I rolled a ball on a sheet and you whipped it, the ball would go all over the place. That’s actually what happens in spacetime. So anyway, it’s a fascinating subject to try and figure out what fabric you’re working on when you’re trying to do physics.

[03:39.7]
And equally, I think it’s a fascinating subject to understand what fabric you’re working on when you’re trying to build a schedule and a project. So there’s three areas here that really matter. Number one is calendars. And these can get very complicated.

[03:55.7]
But really calendars are different ways of counting. And I’ll get into that. Number two is resource adjustments, which isn’t just about adding or subtracting people. It’s actually about the productivity graphs that humans and machines make.

[04:14.2]
And they’re not linear and we get into that too. And the third is constraint adjustments. So I’d highly recommend a good read through this. Hopefully it should be quite interesting. But the very important. There’s four very important points that I kind of want to draw out for you on this video.

[04:32.7]
Number one is that there’s different kinds of time. So there’s real time or clock time, which is this. Everyone exists, everyone experiences in the same way. There’s 24 hours to a day. Then there’s work time, which not everyone experiences in the same way.

[04:52.7]
And that’s really when you turn up to work and when you go home. So some people can do 10 hour days, some people can do 6 hour days, some people can do 8 hour days. That varies. But within work time, there’s effective work time, which is the time that you are directly doing activities past a threshold pace level.

[05:16.1]
And that past threshold pace level is a very important point. You know, we’ve all turned up to work and gone, right, I’m going to get a coffee and I’m going to get, you know, a little snack and then I’ll sit down at my desk and I’ll figure out what that isn’t. Effective work time. Because I haven’t started, I’m at work, but I’m not working equally.

[05:35.3]
We all know what it’s like when for me I’ve got headphones in and you’re just smashing through work and documents etc. And I’m being very productive. That is very productive. Third is, you know, there’s some people who will sit there and work unbelievably slowly.

[05:51.9]
And you know, the way to think about this is time moves differently from for example me and you to someone like that where we might achieve in one hour what someone else achieves in four hours. They’re not the same thing. It’s a threshold level of productivity that leaves on leads on to what’s in resource, adjustments, which is productivity curves.

[06:16.0]
So there’s a couple of concepts here, but the key thing is that just like our activities and the uncertainty of activities, productivity is a curve. And think about this. Going for a run, let’s say that we were all fit enough to run 10 kilometers.

[06:34.3]
If you started that 10 kilometers at a flat out sprint, you would die pretty quickly, get exhausted and the rest of it would be slow and painful. If you were to just walk it, that 10km would take you an incredibly long time.

[06:50.2]
There’s an optimal path which is where you start with a, you warm up, you start with a good pace, you then hold that pace and then as you get close to the end, you’re getting more tired but you’re really pushing and holding that pace and then you stop. So the most productive work generally looks a little bit like a rectangle but with curves and smooth edges at each side that comes on to the third point which is exhaustion.

[07:18.8]
But you can have short and long term exhaustion. So short term exhaustion is like sprinting. So if we were to sprint, we would, you know, our speed would die off very quickly. Short term exhaustion really is associated with either task or day activities.

[07:38.2]
So you know, if you’re doing something like welding, which is incredibly requires incredible concentration at times, if you just make someone weld for eight hours without any breaks or any lunch, the quality or the speed at which they weld is going to deteriorate as the day goes on or the probability, the quality dropping is going to go much higher.

[08:01.9]
So you have to consider exhaustion within that. The same with a day, everybody comes in and sets up in a different way and they set down in a different way and they need lunch. So there’s a natural drop off at the end of the day and the startup at the next day, which isn’t as perfect as, you know, we get to 5pm and then suddenly like a machine, we just stop and close our eyes and then the next day at 9am we open our eyes and just start immediately.

[08:28.6]
Being product, there’s certain sweeps. Long term exhaustion is like machines breaking. So you know, I was doing some housework last weekend and the drill, it wasn’t a brushless motor I was using, the motor burnt out.

[08:47.4]
Now if you think about it, if I had used that drill, let’s assume that the pace that I was using that drill is what made it burn out. But if I was using that drill a little less fast, then I would have had to slow down and let it cool down each time.

[09:08.1]
And that would have taken a certain time. But because I pushed it, it broke and I had to just completely stop work for the entire day because I had to go out and get a new drill. Sometimes slowing down so that things don’t break like people or machines is actually better for acceleration than trying to go really fast and then things breaking and then it taking a long time to fix them.

[09:32.2]
Tunnelers know this very well. You do not want your drill breaking when you’re tunneling, otherwise it’s months of delay. And the fourth, the fourth element of this is the resource, what I call the resource effective working time equation.

[09:47.9]
A bit of a mouthful. I can think of a name at another time. But it’s really about thinking okay with all of this, how do we maximize productivity within a space of people or machines within the context of projects such that we can accelerate projects.

[10:06.4]
And it’s very simple. It’s just the total effective working time. So the thing that we’re trying to maximize is equal to the standard effective working time, which is don’t change anything, just measure people and see what happens. Times a volume factor which is if I have one person, what if I threw 10 people on, would I get 10% more work done in the same real time?

[10:31.7]
Then you’ve got a coordination factor which is well, if those people have to work, have to collaborate and work together, dependent on if they’re well coordinated or bad badly coordinated, I could actually get less production or more production.

[10:49.0]
And then there’s a disruption factor which is people in getting in each other’s way. Because if you’re in a tight confined environment and you’re doing welding, you can’t just throw 2 million people in the room and have all welding done in four seconds. It’s not a computer game. There are actual physical constraints around this.

[11:08.0]
Now it’s more of a thinking of these. The final thing, and the key thing I’d take away from this section, is that very, very, very few projects actually measure effective working time properly. And if you’re in a large organization like a general contractor, measuring effective working time properly and then having all of that data available to the schedulers, planners and risk managers who are planning the job to really is very important for acceleration analysis and deceleration and speed, etc.

[11:47.7]
Not many organizations have come across have got that perfected. A lot of them have got something, but most of them, if you probe, if you probe one or two steps, it’s a house of cards.

[12:06.1]
Like, we’ve got productivity rates. Okay, do you have productivity, rates of different teams in different geographical areas? No, we’ve just got an assumed productivity rate across the whole company. Okay, how did you calculate that assumed productivity rate? Well, we measure it from the SAP systems or the ERP systems.

[12:27.9]
Has anyone gone in to verify that those are the way it is and that people aren’t just booking to certain codes? It’s a house of cards that falls down. To fix this, it can be as simple as a project manager going out onto the site with a stopwatch and speaking with site teams and measuring it properly.

[12:48.2]
And with that, we’ve covered all of the four buckets of areas, within the acceleration equation.

[00:00.8]
So predictability. Now this is a very quick chapter. I put it in there because a friend asked me to. And it came across from a debate, where I wasn’t quite drunk, but I’d had a couple of whiskies, on acceleration, predictability being the same thing.

[00:17.8]
And the conclusion of that is they’re not the same thing. And I’ll give you a perfect example here. For acceleration, I want to in some cases maximize uncertainty. I want as many opportunities to go faster as possible. So I can do, I can do long tail slicing, but I can do opportunity creation.

[00:37.7]
For predictability, if my goal is to have the most precise finish date, I actually want deceleration. So I’ve got lots of float in my project and I, I don’t want any of that opportunity or uncertainty.

[00:56.7]
I just want an absolute point here. So it’s more to do with the goals and the incentives. Now when I sat down and thought about this, predictability is actually far more complex than acceleration from a physics perspective in projects.

[01:14.5]
And it’s because predictability deals with the epistemology of knowing, which is that if I said I want perfect predictability of scope, okay, that’s a question of does scope exist or not?

[01:30.8]
And that’s a much harder question to answer than will this welding task that we’ve done 15 times behave the same way as the other 15 that we’ve done. They’re different kinds of questions.

[01:47.3]
So because of that, if we think about the types of predictability, just like in this book, we looked at the eight types of acceleration which were two by two by two, which gives us eight predictability balloons out of proportion.

[02:05.3]
And there’s actually 144 that I’ve managed to identify within this. I haven’t gone into great detail. The point of this chapter, well, there’s two points. One is to basically say predictability and acceleration are not the same thing and they can actually be counter to each other.

[02:25.8]
Number two is that there’s many aspects of the, the scheduling or the projects world which can have physics applied to them and can actually get pretty damn detailed pretty quickly.

[02:45.1]
But the process of how you think about them is the same. So number one is define what it is and say all the different types they are and have the variables like the 2 by 2 by 2 or here it’s the 4 by 2 by 2 by 3 by 3 and say, okay, then you go, okay, how do I measure each one of these?

[03:07.7]
And then you’d have some kind of predictability equation which I have thought about, and then you would break all of those components down into the individual techniques of predictability and expand upon them. It’s the same method to a different

[00:00.9]
So we’ve come to the last bit of the book, but it’s definitely not a tail off at the end. This last bit of the book is the practicalities. Because up to now it’s been a lot of thinking things through from first principles but not having the focus on how to effectively apply this in a real practical concept of the business that you’re in.

[00:24.2]
But we’re in business and the only thing that matters is the thing that is implementable, not the thing that is the prettiest idea. This chapter is about, that exact subject. It’s how we apply this. The start of it is just a summary and I would just personally bookmark.

[00:42.3]
You’ve got the eight types of project acceleration, how you measure all of them, the acceleration equations, every single technique on page 184, all the different areas that we haven’t analyzed, such as resource control, management control, logistics control, portfolio control, supply chain control, etc.

[00:59.9]
And then we go into implementation. So the first is, baseline and change management acceleration doesn’t work at all if one, people aren’t cognizant that we’re accelerating a model, not real life, and two, the model isn’t change controlled.

[01:18.0]
If there is loose change control on the model, then we are doing maths based on sand and it’s all pointless and useless. So there has to be good change baseline management to even start to do this.

[01:37.6]
And I define to an extent what good is here. And it’s really sequentialism. So for example, if we do something that accelerates the project and then someone else does something that decelerates the project, it is untrue, to go, well, it was pointless to accelerate because we’ve ended up slower than we are.

[02:02.3]
If we hadn’t accelerated, the thing would have been down here. So we one step at a time. Number two is about the stages of delivery. So it’s about how you actually think about accelerating projects when you’re in business case and concept stage, and then how you think about it when you’re in early execution versus late execution.

[02:24.5]
The same kind of thinking is point number three, which is levels of analysis, which is how do you actually analyze at a very high level when you’ve got a level 2 or 3 schedule, or at a low level when you’ve got a level 5 or 6 high level schedules are much more associated with strategic decision making, which is really.

[02:45.0]
And by strategic, what I mean is the irreversible allocation of vast resources. So a direction, a time, money, a location. Whereas, low level acceleration is much more associated with the coordination of tactics, which is the movement and combination of finite resources in a short amount of time.

[03:08.6]
Point number four is actually a philosophical point which is about thinking in reverse. And this is, this is really about the kind of counter philosophies that different people on the project need to actively have. So for example, if you’ve got one team that’s trying to do the project in the fastest, best way possible with the highest level of quality, then you need another group of people, normally executives, to focus on all of the things that could go wrong in the project to prevent them from failing.

[03:41.9]
So if you think about it, how do you achieve success? You either try and achieve success or you try and prevent failure. And those two are not the same thing we’ve talked about a few times in the book. After that we’ve got the two missing KPIs, which I’ve actually done an episode with Micah on our podcast Beyond Deadlines about, you can see the whole book, a huge part of it is about uncertainty, control and risk control.

[04:09.7]
And no one measures those with a simple KPI generally on projects. So I propose the very simple KPIs. It’s the average in the distribution, but it’s the average in the distribution geared against a certain, what I call it a death line, which the average is very simple.

[04:31.4]
If I wanted to run 5k in 20 minutes, then I need to do a kilometer in four minutes. Or if I wanted to run five miles in 20 minutes, which would be unbelievably fast, I’d have to do a mile in four minutes. That’s just the average. If I do my first mile in 7m, probably not doing the 20 minutes.

[04:50.4]
The volatility is. Okay, well, under all situations I can have, you know, let’s say I just kept sprinting and stopping and sprinting and stopping. Under all situations, I can only have a certain level of volatility before it becomes extremely unlikely.

[05:12.6]
I’m not going to make my 20 minutes. It’s, a more complex thing to get our head around. But it’s a very simple KPI to measure. Then we talk about, predictability a little bit more. Then we go into teams and processes and teams and processes is actually the most important one to me.

[05:30.9]
The reason it’s the most important is because how you actually implement capability in companies is through people, processes and tools. Which by the way is just a way of saying adaptability, consistency, machine based repetition.

[05:47.2]
It’s just different ways of operations management. But a huge part of this book is mathematics and actually a huge part of this book is execution and practical people and sight skills. Those two are not the same thing.

[06:03.9]
And I do mention in here like I’m pretty good at the mathematics and I’m decent at the site execution, but I am by far not the best person at site execution. There are, there are project managers and superintendents on the ground that are infinitely better than I am, but I’m pretty good at the maths.

[06:23.1]
And here it’s to accelerate you actually need both of those things, you need a few things. And it’s a single person doesn’t have to be all these things, but a team does. So think about how we’re structuring teams both at the local level and at the corporate level.

[06:44.2]
So for example. Do we have practical experts on the ground? Yes, we really should do with some knowledge of acceleration. And then do we have some people in the center who are enormously mathematical that can come in and do the analysis very quickly?

[07:00.7]
That’s an economies of scale and learning proposition. Or do you forget the center and do you take one of those people and put them in that team, have them operate? I don’t know. It’s really a question of the context that you’re in. Then the final two are really about the simulation methodology and the future.

[07:22.7]
The simulation methodology that we use typically in projects for uncertainty control is a Monte Carlo simulation which is essentially just a wobble, a wobble engine, you pick points, see how they work and then do it thousands of times.

[07:38.9]
It’s just a sampling engine. It’s wrong. And I just want to point out we know, you know, like I said, it’s not about the real world, it’s about the model that we’ve built about the world and the model that we’ve built, that uses critical path method and Monte Carlo we know is wrong.

[07:56.2]
The researchers and the mathematics experts in projects know that it’s wrong. But it’s right enough that actually fixing it would actually cause more problems than it would solve.

[08:13.4]
Because to fix it you would actually have to implement a more quantum approach to, to probabilities in projects. And number one, we don’t have the data. So you know, it’s a fart in the wind, it doesn’t matter.

[08:30.8]
And number two, it’s unbelievably complicated, which means that you’d lose 99% of all people. Once you walked in a meeting and started talking about the quantum mechanical emergent effects of the uncertainty of tasks, you’d be like, okay, so to actually achieve something practical, it is better, to have a more simplified, wronger, model of the world than to have an incredibly complex, righter model of the world.

[00:01.2]
That’s it. We get to Mathematics is the Future. And I talk about this being, mathematics being the future because really of everything that’s happening, in the world right now. Artificial intelligence is mathematics, software, is computer science, and computer science is mathematics.

[00:24.9]
We’re going headlong into a world where more of our work experience and more of our, societal experience is being defined by the mathematics we create, or more specifically the applied maths that specific individuals deploy that has reach to millions of people.

[00:52.3]
Projects is not going to escape from this. Hopefully in this book you’ve seen, I haven’t made an argument that acceleration in physics is about maths. No, it’s just, it’s factually about maths. I’ve just tried to evidence that.

[01:08.6]
But aside from this, I run a company that builds artificial intelligence that fundamentally relies on mathematics and mathematics in computer science to do work within the scheduling domain.

[01:25.7]
And that is the direction the world is going. So all I’d say here is we don’t need to, everyone doesn’t need to learn the maths. I actually don’t know all of the maths. Some of it’s too hard for me to understand. But we need to understand the philosophies of the environment and the philosophies of the maths that’s being applied to the environment and that is doable.

[01:48.2]
And that was the goal of the book. The final thing I really want to mention here, before we finish is I truly believe that anyone could have written this book.

[02:10.4]
And I don’t mean that in terms of some, some humble note or something like that. I mean in terms of, I wasn’t born with the ability to think about project acceleration in this way and then write this book. I was trained by people and given a set of skills, certain unique skills.

[02:31.7]
If we’re taking a quote, really it’s just skills of physics, and maths, skills of business, skills of projects and skills of logic. So if we think about this book, I’ve just taken a premise, a slightly contrarian premise, acceleration is mathematical.

[02:55.6]
And then I’ve just drilled into that first of all by lexicons or definitions. Well, what is acceleration? What is it in projects? And what kind of types and frameworks can we build around that to be able to pick which one applies?

[03:12.0]
So framework thinking. Then I’ve come up with an equation based on first principles, thinking of the model that we’re using. And then I’ve just gone through a large journey of exploring and thinking about how you’d break down each bits of the curves and the maths and then finished up, with thinking about the practicalities of execution, which is really about the processes and the people and the teams that you need to build to make this practical.

[03:46.1]
None of that is. None of that is actually even uncommon. Like most, almost every single manager I’ve met thinks about processes and teams slightly few of them, have the skill sets to think in frameworks and structured thinking, but everyone has the way to think about projects.

[04:06.9]
Slightly unique is the frame of thinking about physics and maths, but you see how it’s just combining ideas from different areas with a logical thinking mindset. And if there’s one really key thing I’d like you to take from this is that if you develop that logical thinking mindset, you can create some incredible things yourself using the unique knowledge sets that you have.

[04:43.1]
And I would heavily encourage as many people as possible to start thinking more in that way. And right at the start of the book, I write a phrase that I’ve got on my whiteboard up, there that I try to live each day with, which is think bigger, be better, do more.

[05:02.6]
This is thinking better, or thinking bigger and being better and doing more is just sitting down for hundreds and hundreds of hours and actually trying to write this thing. So I really do hope you enjoy it.

[05:18.0]
I would love to hear feedback on it. Please let me know if it changes your projects in any way, because that would make me happy. Thank you.