Nov
29
A Brief Introduction to Critical Paths
November 29, 2005 |
The first step in figuring out how long a project is going to take is to identify the critical path. Without getting too much into the details (that’ll cost you; I don’t do PM courses for free although my fees are reasonable) you work out the critical path by:
- Listing all the tasks that have to be completed over the lifetime of the project;
- Figuring out the order in which they need to be completed;
- and finally picking out the series of tasks that will take the longest amount of time to complete.
That series of tasks is the critical path. It’s called that because it determines the length of time the project will take to complete. The key insight of critical path theory is that if a task isn’t on the critical path, you will accomplish nothing by trying to speed it up. Only tasks on the critical path matter. Similarly, a delay of a task on the critical path will delay the completion of a project, whereas a delay off the critical path will only matter if it changes which path is critical.
So, if you want to “crash” a project, you have to focus on the critical path. You’re also going to need software to help you, such as Microsoft Project or Open Workbench. Again, basically, there are three things you can do to speed up the critical path.
First of all, you can move tasks off of the critical path. You do this by looking at the dependencies of those tasks and asking if they’re all really necessary. Can we start work on a project before the contract is finalized? Are there points where oversight, reviews or presentations are slowing things down? Maybe, instead of locating an office for the project team, we’ll have them work from home. You get the general idea. Essentially, you’re pulling out things you should do and reducing the project to the things you must absolutely do. Taking this stuff out isn’t free; it’s likely to introduce risks to the project and also potentially reduce the usefulness of the results–but it can get things done faster.
The second is to modify the logical dependencies. Can we do some things in parallel, like start making our product before we have the packaging and storage facilities worked out? Can we start designing based on a draft version of the product requirements and finalize our design when they’re signed off? Again, this increases the risk level of the project, because in most of these cases you create a possibility that you’re doing a bunch of work that will have to be thrown out.
The third is to speed up tasks on the critical path by throwing more money or people at them. If you need to produce a certain number of goods, get a second factory to churn them out. Split the work up between two people. In general, you will only save a limited amount of time this way. As a rule of thumb, expect that cutting the time in half will cost a lot more than twice as much. If you split a person’s workload and give half of it to someone else, it won’t be done twice as fast because the two people will probably need to talk to one another and co-ordinate what they’re doing.
Some tasks can’t be split at all. Some tasks can’t be split up–a famous saying in project management is “two women can’t produce a baby in four-and-a-half months” (although if you need two babies, you might be in business). No matter what, there are always hard limits to how quickly a project can be done.