Plans and planning techniques: Critical Path
It's April, so that means it's time for a new blogpost! This time, I've decided to dig a little deeper into the technical aspects of projectmanagement and write an article on planning techniques. We'll examine the various popular methods of planning projects and see what makes them tick.
It is important to realize that planning is not always mandatory. As I described in my previous article "Paper, scissor, rock", it's easy to get lost in paper, especially when you plan things just to plan them. When you do start planning, ask yourself first whether or not creating a detailed plan and breakdown really, really contributes anything to the project.. don't become a paper tiger!
The various plans
There are many levels of planning that can be done. When we look at a method such as Prince2, we'll discover that there are projectplans, stageplans and teamplans. For every individual section of the project, a planning can be made. At times, it can be useful to create a teamplan (a detailed planning for one team during that phase). However, that teamplan does not need to appear in the same detail in the projectplan; after all, with a large project, this would only clutter the transparency of the projectplan.
Then we have the plans for the various aspects of a project, such as:
Communication plan: A plan that describes what, how and when communication is done throughout the lifecycle of a project.
Quality plan: This plan describes how we ensure the quality of the project.
Risk plan: A plan that deals with risks and the management of these risks.
Oh, so many plans... as the saying goes: "Too many clowns, not enough circuses". It's enough to drive anyone insane! Thankfully, it's not necessary to deal with all these plans in detail. Sometimes, we can leave out some of these plans, or just write them down on the back of a beercoaster as a reminder (if, like me, you prefer doing your creative thinking in a bar).
For now, we're going to ignore the communication plan, quality plan, etc. and merely look at the planning of activities. Believe me, it's enough to begin with.
As a start, we'll examine two fundamental approaches to breaking down a plan into little pieces.
Product-based or work-based
A projectplan will always have a goal. This goal could be the constructing of a new factory, implementing a new productline, moving offices, etc. Depending on the goal of the project, one out of two structures will be preferable. Let's have a look at these structures:
PBS (Product Breakdown Structure): Prince2, as a method, is product-driven. This means that the project is broken down into several 'products', such as 'a new factory', 'a new pair of pants', etc. Following the train of thought that we are aiming to complete various products, we can break down these products in little subproducts. Again, we can break these subproducts down even further, until we reach a level of detail that may seem ridiculous; it's probably time to stop at this point.
An example: Say that we are going to have breakfast. We've been out the night before, and as the hangover plays merry hell with your brain, you decide to be precise in your breakfast (or perhaps you just have too much time on your hands) and plan the creation of breakfast. The main product of this project would be easy: Breakfast.
So, what is this product 'breakfast' made up of ? Well, there'll be coffee. And scrambled eggs. Some orange juice, perhaps. I'm sure you can let your mind wander and think up something. Already, we have three subproducts, being 'coffee', 'scrambled eggs' and 'orange juice'. Again, we can perform this little procedure, and break down these products even further. 'Coffee' becomes 'coffee', 'mug', 'spoon', 'sugar', 'milk'. 'Orange juice' becomes 'glass', 'oranges', 'juice machine', etc.
I'm sure you see where this is heading, and that it is easy to get lost in details too soon. Try to remember that a planning is supposed to help you control and schedule your products, not demonstrate your intense knowledge of how to make a good breakfast, shall we ?
Then there is a more popular method, which is activity-based:
WBS (Work Breakdown Structure): Contrary to PBS, WBS defines a project as 'a lot of activities that have to be done to achieve something'. So, instead of defining products, we define activities. Just as with PBS, we can then break these activities down into subactivities. So, instead of the product 'breakfast', we could define the activity 'make breakfast', which contains 'scramble eggs', 'pour coffee', etc. I'm sure your creative mind can break down the above breakfast-example even further.
Even though these structures seem rather similar, they will give different results and therefore, different planning. Try for yourself and see!
Now that we have examined the structures available to us, let's see how we proceed. Let's assume that we used PBS to breakdown our little breakfast-project. Below, you can see how a planning like that would look (that is, if I manage to find the right buttons on this blog to upload a picture...):
Ah! Success! OK, so it's slightly oddly sized at the moment, but I'll fix that later..
There are a few things that one would notice from this planning. First of all, there's the fact that all activities seem to take the same time. This, of course, is nonsense, but right now, I don't feel like putting in any times. Not yet.
Second, and very important, are the sequence in which the activities take place. Apparently, we are able to scramble eggs, make coffee and make orange juice at the same time. However, let's keep in mind that we're still hungover, so multi-tasking is out! For the sake of argument, let's presume we can only make coffee and orange juice at the same time. For the scrambled eggs, we need our fullest attention. Also, as we only have one electrical socket, we'll have to choose: Bake eggs first (let's assume that your stove is electrical) or make coffee first ? As it's nice to have a cup of coffee while baking, let's start with the coffee first. In the meantime, we'll make orange juice, which doesn't take as long as the coffee. Our planning will change:
Note: No, it doesn't take me several days to make breakfast, but for the visibility in the Gantt-chart, it's easier to use days, instead having to alter all the taskdurations and tell Project 2007 to use hours. Sue me, I'm lazy. Also, I altered the task-layout to create a more readable Gantt-Chart, as you may see.
As you can see, there is a clear path that is walked through to achieve our great project 'Breakfast'. It is this path that I want to touch upon now, because it's a very important part of planning. Can you guess ? Yes! It's called 'the critical path'.
The critical path is a chain of tasks that has to be completed in order to achieve projectsuccess. In this case, we need coffee, orange juice and scrambled eggs to enjoy a good breakfast. Notice that in the example the product 'orange juice' does not have a direct impact on the other tasks. As the tasks themselves also take a lot shorter than the other tasks, we do not need to focus directly on this task. Only when there is an extreme delay in this task (perhaps you still have to grow the oranges) will the project's end date become affected. The activity is in the critical chain, but there is a lot of margin for delay in this task.
The other two tasks, however, need more attention. Any delay in the coffee-making will also have a direct impact on our scrambled eggs. As it is early morning, the chance that you forget to turn on the coffeemachine and get into the juice-making is very likely. As a result, the task of making coffee will take more time, the scrambled eggs will be prepared later than planned and by the time we've finished making breakfast, it'll be time for dinner.
A planning like I've put up above is all nice and well, but to determine the critical path, it's common practice to use so-called network diagrams. These diagrams represent all the activities in network layout, making it easier to determine the critical path of a project.
I won't go into the two different types of network diagrams common to the CPM (Critical Path Method), but suffice to say that I'll be using an extremely basic AON-diagram (Activity On Node) instead of the AOA-diagram (Activity On Arrow) as the former is less prone to error than the latter (if anyone's interested, I'll write on article that goes deeper into CPM for next month).
Below is a very basic AON-diagram for our little breakfast-project:
The various circles (or nodes) represent activities. In this case, the following representation is used:
A: Turn on coffeemachine
B: Pour coffee
C: Scramble eggs
D: Squeeze oranges
E: Pour orangejuice
F: Serve breakfast
Suffice to say that this is a very basic representation of all the activities in our little project; however, it'll do to bring across the basic idea of a network diagram. Represented visually, it's a lot easier to perceive that the activities A, B and C need to be performed in sequential order to get to serving breakfast. Also, activities D and E are done in sequential order, but parallel to A, B and C. However, to get to F (serving breakfast) we'll have to go through the entire network to achieve projectsuccess.
Note: A network diagram is more often a lot more complex and though-out than this one, and there are a lot more details to consider. These are related to network routes, predecessors, weights, etc. Again, if there is enough interest to go into detail on this, I'll write an article on it.
There are various conclusions to be drawn from this article. One of them is that planning is not something you do once. Time spent on activities change all the time, and it is necessary to review your planning constantly, or at least very regularly. Whereas planning is iterative and often vague (especially with future events), critical path analysis is (if you do it well) something that needs to be done only once and after that serve as a contineous and invaluable tool. Critical path analysis makes it easier for a projectmanager to determine the priority for teams and their activities by keeping an eye on those activities that impact the critical path and those that don't (in a complex project, there will always be side-chains). Though Gantt-charts (for those unfamiliair with the term, a Gantt-chart is the graphical representation to the right of our little PBS in the first two pictures) can be used to keep an eye on the project's progress, it's often a lot easier to stick to the network diagram instead. One reason for this is that in a Gantt-chart, a simple activity may seem like a little thing that can be done in an hour, while in a network diagram this activity will be seen as an important junction in the critical path. Especially with complex projects, it's easy to miss an activity in Gantt-charts or breakdowns.
There is also another important aspect of critical path analysis, which is the improvements and 'out of the box thinking' the critical path often bring forth. In our little breakfast-project, we've placed the coffee-making and scrambling of eggs in sequential order. Doing so has had a direct impact on the critical path, prolonging the duration of the project. In our network diagram, we notice a sequence of activities that have to be completed before we reach that final node F; serving breakfast. By examination of the network diagram, we might be triggered to suggest the installation of an extra electrical socket, allowing us to place some activities in parallel order; by doing so, we'll allow future projects to be finished swifter. This is more visible in the network diagram than it is in the Gantt-chart. Another wonderful aspect of network diagrams and critical path analysis!
By managing your projectplanning through the use of critical path, you're more likely to complete your project on time and within budge by focusing on what matters.