Off the Critical Path

A path running through a flat plane.

I've had this tool on my mind for a while now, since we're currently going through a house move and there's a host of critical tasks involved. There's a lot that can be done with it, including risk analysis, programme management, and it's another of those tools that is straightforward and mainly involves working methodically through what you're trying to do.

When to Use It

Critical path analysis, or the critical path method, is about breaking down one big project into atomic tasks, working out the dependencies, and then determining what is (and is not) critical.

As such, it's best used when you have a complex project with a lot of moving parts. Especially when you have multiple people working on that project, big deadlines, and limited resources. We'll be looking at a simpler one, but you can take the same approach with much more complex workflows and have an idea of whether a deadline is possible or not, and what more is needed to make it achievable.

How it Works

Start off by taking your big task. Since this is partly catharsis for me over the house move, I'll be using that. So, the big task is to move into a new, livable home with all people, property, and pets intact and healthy.

Breaking that down, we have selling the current house, buying a new house, packing everything, transporting everything, unpacking everything. At least that's what we have at first glance. If you look back at some of the previous tools covered, breaking things down is a common theme. Lets start with selling the current house, and see if we can get it down to atomic tasks.

A diagram showing the steps of house selling, from preparing for sale to completion. Completion is highlighted in red while other tasks are green.

All looks very straightforward. The green tasks are completed (you don't have to highlight them as this is usually a planning tool, but they're useful when we start going into dependencies). What about the buying piece?

A diagram showing the steps of house buying, from determining budget to completion. Completion is highlighted in red while other tasks are green.

Also very straightforward. And moving?

A diagram showing the steps of moving between houses. The last three of five stages are highlighted in red.

A few more reds, but all looks pretty straightforward.

Of course, these aren't independent processes. Their dependencies matter - some can't start until others finish, which means those reds could have serious knock-on effects.

The three previous diagrams interlinked, showing dependencies.

Well, now we see there's a problem, and probably something we've not accounted for. If there's a delay between the completions, where do we go? Especially when they may not be under our control.

You can see that some items are not on the critical path - packing and decluttering isn't. Booking movers would be, except we can remove it from there by adding a contingency in the form of temporary accommodation - which allows us to move out at a time of our choosing.

This is a very simplified example, but it shows that you can find items which are on a critical path and remove them from it. This makes sure you have flexibility, and if you're facing resource constraints you can make use of them when they're available.

Adding details such as timelines, resources needed, highlights, etc, is all helpful with more complex projects - but the core concept is to map dependencies and work out what is critical, what isn't, and what critical tasks can be made non-critical.

Subscribe to Talk to the Duck

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.
jamie@example.com
Subscribe