Now that we've created some dependencies on our test project, it's probably time to take another detour from the actual doing and discuss a bit more theory.
If you have any involvement at all in PM on a regular basis, you've probably heard of the Critical Path Method (CPM) of project management. Critical Path is a mathematical method of figuring out what your project tasks (the WBS), the time those tasks will take, and the dependencies between the tasks, mean in the greater sense of your project schedule as a whole.
I'm not a math-y person, but basically, the calculation of CPM is based on determining the longest path of the tasks you have planned until the end of the project, and then calculating the earliest and latest that each task can start and finish without dragging the project out beyond its due date. By figuring it this way, the method decides which activities are "critical" and which can be delayed without pushing the project beyond its deadline. Those tasks on your task list which aren't deemed critical have what is called "total float," which means those tasks can be delayed without extending the project.
According to Wikipedia, critical path is, "the sequence of project network activities which add up to the longest overall duration. This determines the shortest time possible to complete the project. Any delay of an activity on the critical path directly impacts the planned project completion date."
Originally, CPM was based on logical dependencies and was very much about scheduling (which is one reason you need to be real about your task scheduling instead of just making up random numbers that sound good), but it didn't necessarily take into heavy account the resources necessary for a project task, and how much resources can affect duration. But of course, your schedule can be highly variable dependent upon your resources, so resource leveling, a method of allocating your resources within your project schedule to resolve resource/schedule conflicts along the critical path, was added to the CPM to more realistically calculate the actual time a project is going to take.
Changing one variable -resource or time- can cause your entire critical path to shift, and it can throw your entire project way off course. Since all of your project tasks are linked together with dependencies, and are either duration- or resource-dependent, when you're estimating your task scheduling, it will behoove you greatly to finely drill into the actual duration or resources that will be required to complete the task. While the algorithm used for CPM has some flexibility built in with float and with fast-tracking (performing more tasks in parallel) and crashing the critical path (adding more resources to shorten the path of an existing activity or to keep it on-schedule), it cannot be stated strongly enough that when you are making your estimates for a project task, the closer you come to making a real estimate, the better your chances of actually completing your project before the deadline.
So, though it may be tempting to throw around guesstimates when you're determining your task scheduling and resources just to get something down on paper (or in Project), you're not doing yourself any favors by cutting those corners. You could wind up messing up your entire project.
The way I understand critical path, it's kind of like a time travel episode of a sci-fi show. The critical path you set up for your project is one universe, or reality. But if you tweak one little variable, even just a leeeetle bit, suddenly, you could find yourself in a parallel universe -on a different critical path- and the outcome of everything will be different.
Of course, now that I've given you this dire warning about altering the universe with your project scheduling, and I Google "Microsoft Project" + "Critical Path" to see if that's the default algorithm Project uses, I come up with a Microsoft Project blog post that basically says, "Eh, critical path. Sounds scary, but really isn't so much a big deal."
So I guess the truth lies somewhere in the middle: critical path is important; it's a core piece of successfully planning and executing a project. But it is adjustable. As long as you make reasonable estimates for your project tasks, you should be golden. No need to be all Chicken Little about it.
And hey, at least you don't have to make all these calculations manually, right?
Aug 07 2012, 09:30 AM
| Edit this post
Pamela Flora is currently the Marketing and Administrative Coordinator for the D.C.-area office of Innovative-e, Inc., where she has worked since March 2011. She has previously enjoyed work in both the public and private sectors as a technical writer, as well as taking the occasional freelance gig. While her current duties encompass a plethora of tasks both mundane and complex, they did not include project management until recently, when she was given the opportunity to explore project management from an in-the-trenches POV and document the experience in this blog. In her spare time, Pamela likes to hang out with her five kids, paint, write, spend quality time with her DSLR, and, now, read project management books. Though she is only infrequently on Twitter, you may follow her there just in case she feels compelled to tell you what she had for breakfast and you feel the strong desire to know: @puckish222.