When I was a business analyst working on a human resource talent acquisition implementation, six weeks out from the

launch date the project manager rushed us into a room and asked us to figure out the critical path. I had heard the term critical path before, but I didnt really understand what it meant. I knew the project was critical to the HR organization and thought everything on the project was on a critical path. Project managers will be amused that we were trying to figure out the critical path with six weeks before launch rather than prior to project execution. In hindsight, the project manager shouldve known the critical path earlier and been monitoring the schedules progress. I still find it puzzling that the project manager asked a bunch of business and system analysts to determine the projects critical path. It wasnt until I shifted my career into project management that I gained a better understanding of the critical path and its impact to a project. The Project Management Body of Knowledge (PMBOK) defines the critical path as the sequence of schedule activities that determines the duration of the project. Project managers can also apply the critical path methodology technique to determine the amount of float on various logical network paths in the project schedule network to determine the minimum total project duration. Critical path explained If youre just as confused by the PMBOK speak as I was, let me restate it in a way thats easier to understand. The critical path is simply all the tasks that determine the end date in your project schedule. If one of those tasks is late by one day, then your project end date will be extended by one day. Oftentimes, there will be tasks that are not on the critical path; this is due to the slack in the project schedule. If you refer to your current schedule, you can examine the Gantt chart and quickly identify the tasks that have some float compared to the tasks that have no slack. Slack is the amount of time a task can be delayed without impacting the start date of a subsequent task. The critical path methodology is simply a technique to identify all the tasks that will directly impact the project end date. Figure A depicts a Gantt chart with a set of tasks on the critical path. Figure A

Critical path in Microsoft Project

In Figure A, there are five tasks in the project schedule and Task 4 is not on the projects critical path. If Task 1, 2, 3, or 5 is delayed, then the entire project will be delayed. If Task 4 is delayed, it has seven days of free slack before it will start having an impact on the schedule. Since Task 5 is three days in duration, Task 4 could have an actual duration of 10 days before it becomes part of the projects critical path. If it exceeds 11 days, Task 4 will create a new critical path. Ill admit Im reluctant to create a network diagram and start the forward and backward pass mechanics. Tools are invented for a reason and, fortunately, Microsoft Project can support forecasting, what-if analysis, and detailed scheduling metrics along the critical path. By switching to different views and formatting the Gantt charts, you can quickly identify and monitor the tasks on the projects critical path. Figure B depicts the free slack in Microsoft Project. All the tasks on the critical path have zero slack in their schedule and thats why these tasks drive the end date. Task 5 has 7 days of slack and is not included on the critical path. By increasing or decreasing duration on specific tasks, you can see the adjustments in the critical path. Figure B

Critical path free slack In my next column, Ill show you how to identify the critical path in Microsoft Project and use the different views to monitor and track the critical path. Critical path and network sensitivity If you want to learn about the critical path and network sensitivity, read my article on Network Sensitivity and the Critical Path. The article features the sample Microsoft Project file if you want to experiment with adjusting the critical path. But surely the critical path in project management is obvious? I'm amused that a project manager 6 weeks from launch had no idea what the critical path was on his project. This I imagine is because he'd forgotten the real reason for being a project manager, which is to get the project launched. Not to pfaff around managing project risk or project quality management. I am 8 weeks away from launch and I have ditched the Project Management Tracking for the simple reason that we now have 7 key dates to hit. If someone can't remember that then they shouldn't be a project manager.

Knowing what the critical path is is vital to understanding how to manage a project and leads onto successful project management. Further it gives you visibility of what exactly you need to concentrate on, rather than being ambushed by all the irrelevant "noise" on a project.

To be honest I thought it was fundamental as well As a developer I want to know the critical path in my areas of the project as well, otherwise I can't even manage my 'small' part of the whole. That's especially useful when I get a plastic PM who doesn't know the fundamentals, and I have to explain them, again.... Try not to be as pushy with the links to your stuff, it's irritating and counter productive. I didn't click on one of them as it makes you look like an up market spammer.

We have to meet legislative demands by legislative deadlines. So our Critical path is effectively all the compliance work estimations/ available developers. Can't miss the deadline, can't do less than the minimum to be compliant. So the bulk of our prioritisation is making sure that gets done and then seeing what value added, market sponsored, and even on rare occasions refactoring/rework can be done on top. Effectively we are doing MoSCoW, and Must is not open to debate, but we have so much flexbility, we 'd have to seriously screw up by the numbers to struggle. Working on that project, I too found it amusing but only later on in my career. On that particular project, one of our team members went to the hospital due to an unrelated accident and there I was in the emergency room with giving a powerpoint presentation and projecting it on the wall. You learn a lot from troubled and failed projects...and sometimes it is difficult to get above the noise.

Critical path is the fundemental reason you plan a project I worked in Naval Ship Repair in the mid 80's and even though I was not a project manager or had any exposure to project management I learned really quickly that the only thing that matter in a project plan was the critical path. Also I learned quickly that the only chart to use to really keep track of your Critical path is a PERT chart. The PERT chart was invented by the US Navy and they classified it for a period of time in the 1950's.

Critical Path was invented separately by Dupont around the same time. Now I have never had a job with the title project manager but if you use PERT Charts then use it to determine your critical path your project planning will be simple. The best way to know your critical path if you are using Microsoft Project is just have it generate a PERT chart. Take a good look at it and it you know the critical path. I have ran project and gave PERT charts to the team and had to explain them. Most people want to use Gantt charts. They are easy to understand but are totally useless to managing a project properly. I believe that if a project manager does not understand this concept then how can they call themselves a project manager. However they have met the criteria of the PETER PRINCIPLE "You are promoted to your highest level of incompetence." Just some thoughts on not understanding critical path and being involved with project management. Not to be critical but ... I agree that critical path (CPA that is, AOA or AON -- aka the CPM/PERT argument -- is irrelevant) is one of those fundamental issues. Having said that we all started somewhere. And new project managers do have a problem figuring out what's on the critical path. Heck, with a complex problem and heavy critical chain effects it can be a problem even for a seasoned project manager to figure out the "real" critical path(s). My big problem is that I don't think this was a particularly good explanation. Using slack to explain why tasks are or aren't on the critical path is somewhat circular. Lead and slack are the result of an item not being on the critical path ... not the indicator of it! Otherwise tasks which do not have either lead or slack would be on the critical path automatically. In a complex project, they may not be. Having lambasted poor Andrew it's now time to comment on some of the other points. 1. It is perfectly possible for a project manager to lose track of the CP. If the project is having high variances (actual to predicted) or has been hit with a number of risk events then it is entirely possible that the CP will change. For that matter it could be that all the remaining tasks are critical and that the CP is a theoretical concept. 2. Dropping Project Management Tracking is a shortsighted response. Project Management has three

key purposes. The first is to get the project done in the shortest (ehh) time it can be completed. The second is to provide a basis so that projects that can't succeed don't get started. The third is to provide an oversight view into the project for those stakeholders who need it. Bluntly, unless this is a real short project, your sponsor, and the related managers are not going to be happy if they aren't being warned about the progress of the project. While I agree that focus is important to sanity, ignoring any topic is suicidal. Your critical project pain points can come from many directions ... time, cost, variance, risk and quality are only the most likely sources. Focusing only on time and hitting the milestones tends to get project managers blindsided when a risk event happens or a task output is below required quality levels.

Re: Not to be critical Hi Glen Thanks for the comments! I don't mind being lambasted My goal was to highlight a key critical path concept that I haven't seen effectively communicated or used in commercial software project management development. In enterprise IT implementations, the project schedule is communicated although the PERT chart isn't as widely used compared to a program milestone chart. If we go into an Agile vs. Waterfall discussion, you'll find the WBS and PERT charts are not actively used. I find there are a lot of difference between commercial and government project management particularly in software development. However, those comparisons are for a future article!

Interesting comment about CPA not being used in commercial IS. That's where I'm from and I cut my teeth learning it. Although I tend to see the results dumbed down for upper management to milestone reporting, I've always seen it used as the basis. Even when we couldn't easily create the network diagram we used the technique and bulled our way through. My own experience is that AOA/AON charts (Pert or otherwise) are used to communicate within the project team and IT while milestones are used for management to keep the info level down. I use the term dumbed down but we're really talking noise levels and cutting off at an appropriate detail level.

My comments on PERT were primarily directed at another comment. I once worked with an engineer who had trained in the company that developed PERT for the U.S. Navy. I've been through the PERT Pro/Con arguments. It's a tool - use it when it's appropriate. You wouldn't hear a carpenter saying that a Robertson screwdriver was better than a Stanley hammer, would you? It's a tool, use when and if appropriate. As for Critical Chain Analysis, it has application to CPA. One of the problems with complex IS projects is that traditional CPA does not include CCA (one more acronym and my head's going to explode! ). As a result, projects with multiple CPs can surprise the less experienced project manager as a CP suddenly appears out of nowhere. CCA would have indicated that a change in CP was possible at that point. (Yes, PERT does try but ...) As for Agile, you don't want to hear my comments. However, even I must admit that there are things that disciplined techniques need to learn. The only difference I've seen between commercial and government is their openness to the latest fad. Commercial is more likely than government to jump on the promise of Agile's money savings and then off again when then next golden bullet arrives. Government is more interested in proving they spent the money wisely.

MS Project caveats for critical path Several caveats must be followed in MS Project and similar tools in order to show critical path and make it really useful. The two most important are 1) Every task must be linked via dependency to at least one other task. 2)Do not put date constraints (must start on, must finish on, etc.) on any task. I hope you will cover these in your next article. Having reviewed hundreds of projects I am amazed that nearly all PMs violated these caveats and crippled the tool, turning it into little more than tedious documentation.