What is the system’s critical path?
So it's doing some study this morning on the unofficial project manager, quite a good book put out by Franklin Covey and it recognizes the problem that many of us in the world right now is actually doing projects.
But we have not been trained to do these projects in an official way.
And so they brought out this cool book, it's called the unofficial project manager.
And I've been learning a lot, it's been really cool.
I have not been formally trained in project management.
But apparently, there's an entire institute that is dedicated, with textbooks with manuals with optimized ideas on how to run projects.
And what I came to realize is that projects are basically a whole bunch of systems getting executed.
And if you put three systems together five systems together, then you get the entire project.
But as I was going through the book, I was interested to see the way that they did the work of the project.
And the first part was very interesting, because it established, Hey, what are we trying to do here? What are the end results? What are the results of this entire project? And in a bigger project, there's going to be multiple results.
It's not just one result.
And so they're like, Okay, well, what are the clear results here.
And within that, then, getting clear on that was very important that just because one person thought that the results should be X, Y, and Z did not mean that others agreed.
And if this is not established early on, then the entire project can easily be derailed and fail.
After that initial establishment phase, then they moved into a planning phase.
And this began with something very interesting, which was, which was risk identification.
It wasn't building out timelines, and Gantt charts, or anything like that.
It was like, Hey, what are the risks that this entire project will fail.
And if they scored high enough on a probability of occurring and an impact, if they did occur, then there should be a formal decision about how you're going to deal with that risk.
So if it was at least a three out of five, on one and a four out of five on the other or higher, then that would be something within that project, a system within that project that needs to be thought beforehand, or invested beforehand to say, hey, this, this could happen.
And if it does happen, it's got a large impact, we should think about how we're going to deal with this.
So having gotten through all of those parts of finally came to the timeline.
And here was some interesting discussion about dependencies.
Now, you may or may not know what dependencies are, they're basically if you've got a system with a bunch of processes, or you've got a project, which with a bunch of systems, and those systems have a bunch of processes, then the dependencies are things that must be done before something else could start.
Now, this would be called a finish to start dependency.
And this would be the most common one, something has to finish in order for the next thing to begin.
But they also mentioned two other ones, which are worth discussing, number one, start to start.
So both processes could start at the same time.
This is extremely useful if you've got multiple people.
And you want to say, Hey, how can we speed this whole thing up? Well, let's get all of the start-to-start dependencies begun now.
And there was one final one which was finished, which means that everything had to be finished before the next process could be started.
So it was like an advanced version of finished to start, except there were multiple processes that had to finish before the next bit could start.
And then out of all of this, with these defined, then this very interesting idea came up about the critical path.
And I was like, what's the critical path? This is an interesting term, you may be familiar with it, you may not be, but it's not the identification of which is the most important processes within the entire project, which is what I originally thought but rather, it is the longest process back to back that must be completed in order to finish that project.
So this gives you interestingly enough your shortest time for completion.
That if any of those processes on a critical path get delayed, then it is inevitable that The project gets delayed.
And this is useful because it allows for the choice about how much leeway how much safety margin do you give.
And the discussion around this is particularly interesting because you might say, well, this entire system as part of the project is going to take a week.
But we know that it is on the critical path.
So I'm going to allow eight days, or in fact, I'm going to allow two weeks and then give two weeks time to make sure that this gets done.
But then you run into the most interesting phenomenon, which is Parkinson's Law.
This says that the work expands to fill the time available.
And you know this most commonly when you have a holiday to get to when you have vacation approaching, and there is a 5 pm deadline on that Friday, after which nothing else can be done.
This allows vast amounts of work to be done.
So as you come into project timelines, you've got these two interesting, competing for demands on how long to make a project.
Number one is, hey, we want to have enough time because this is on the critical path.
If we don't have enough time, then it will delay the entire project.
But on the other side, you've got Parkinson's Law, which says that irrespective of how much time you allow, it will always fill up that time.
So choosing this very wisely is important.
But what you will recognize in this entire discussion from the unofficial project management is the definition of the work, defining first of all of the results, and then what work must get done, also known as what processes must get executed.
And they also include the intermediate tree results that would get created.
And these could be linked to particular milestones where everyone gets together, go, Hey, we're on target, or we're off target.
And what is the impact of this? Now, this is high-level project management, but your challenge most likely is that you have not had much training in project management and status has been defaulting.
So the guys who do this as their job in charge of large projects, are in controlling large budgets, but their work is as applicable to you as it is to the large projects.
And if you know these concepts about project management, then it allows you to get better results for your business for your boss.
If you are the boss, it allows you to get better results from your team.
This all means that you have more effective project completion with less failure rate.
And interestingly enough, if you actually complete a project, you spend 1/3, less than a failed project.
Isn't that interesting.
I thought that was fascinating that a failed project not only fails but also costs more than a successful project.
That's why you should pay attention to learning how to do great project management.
If you want some help with this.
If you are running big projects that have multiple systems with multiple processes, and you want to know how to set them up for maximum effectiveness and maximum chance of success, then head over to www.systemio.dev.
That's all I got for you today.
I hope you enjoyed today's episode.
I certainly enjoyed making it for you as we continue this journey into the power of systems to create results.
I'll see you again very soon.
