Project Management

Critical Path Analysis: The path to project enlightenment

If a project is not incredibly complex, try Critical Path Analysis, a nearly no-tech approach.


The importance of scheduling to a project’s ultimate success cannot be over-emphasized. The "Chaos Report" by the Standish Group and a study by KPMG Canada called, "What Went Wrong? Unsuccessful Information Technology Projects," have both identified schedule overruns as a major cause of project failures.

Tools such as Microsoft Project are rich with features to help manage projects of all types and sizes. Resources can be allocated, reports can be generated and tasks can be scheduled, but the standard Gantt chart with its horizontal bars and milestones is not the only way to represent and analyze the tasks that make up a project. Critical Path Analysis (CPA) is another valuable tool in the project manager’s arsenal.

Connecting the dots
CPA can be done without expensive project management software simply by using a pencil and a piece of paper. It is especially effective when a project is in its formative stages and basic tasks are being identified. As shown in Figure A, each task is identified and then depicted as a line with a dot at each end, signifying its beginning and end along with an estimated time for completion:

Figure A


As with Gantt charts, the lines start at the left and end at the right, so some people like to use a right-facing arrow at the end of each line as shown in Figure B.

Figure B


Database application example
By way of example, let's work through the CPA of a simple database application project.

Note
Please do not concern yourself with what comes first or the suggested lengths of the tasks. This is only an example.

A simplified list of tasks and approximate times for completion might be:
  • Requirements gathering:                   1 Day
  • Design database:                             3 Days
  • Create database:                             7 Days
  • Create views:                                   2 Days
  • Create stored procedures:                 2 Days
  • Design classes:                               2 Days
  • Code business rules:                        4 Days
  • Code CRUD operations:                    5 Days
  • Code error logging:                           2 Days
  • Design GUI:                                     7 Days
  • Create menus:                                 3 Days
  • Establish application navigation:        3 Days
  • Create data entry windows:               4 Days
  • Establish user logins:                       2 Days
  • Create reports:                                 4 Days
  • End user training:                             3 Days

You must finish what you started
After a list of tasks and approximate times required is put together, the next step is to identify the order in which tasks must be performed. In our simple example, database creation cannot begin until database design is complete, but once database creation is complete, other tasks such as creating views and creating stored procedures can proceed simultaneously. As shown in Figure C, when a task is dependent on another task finishing before it can start, the line representing the dependent task begins at the end of the line representing the task on which it depends:

Figure C


When a number of tasks begin simultaneously, the lines representing them can simply branch out from the same point, as shown in Figure D. There is no need to keep the lines straight.

Figure D


Using this technique, we can now build a diagram using all our tasks. If you are using a large piece of paper, you can produce one large diagram with tasks flowing from left to right. You can also do a series of smaller diagrams, as I illustrate in Figures E, F, G, H, and I.

Figure E


Figure F


Figure G


Figure H


Figure I


Identifying the critical path
The next step is to examine the resulting diagram and add up the longest way through from point to point. This is the critical path: the shortest possible time required to complete all the necessary tasks.

In our database application scenario this is:
  • Requirements gathering        1 Day
  • Design database                  3 Days
  • Create database                  7 Days
  • Create views                        2 Days
  • Design classes                    2 Days
  • Code CRUD operations         5 Days
  • Design GUI                          7 Days
  • Create data entry windows    4 Days
  • Create reports                      4 Days

                                             ______

         Total                             35 Days

The simplest way to identify the critical path on our paper diagram is using a highlighter. Highlight all solitary tasks and the longest of all simultaneous tasks. You now know the tasks that absolutely must get done on time (or sooner). Any delay in any of the tasks along the critical path will delay the entire project’s completion time as well as any dependent tasks. The tasks on the critical path should be assigned to your most trusted and reliable people. The parallel tasks with shorter completion times have "slack" and can be assigned to less experienced staff. When tasks with slack are done, resources can be shifted to tasks on the critical path to help them along.

Making changes
You may find ways to juggle tasks or move them off the critical path in order to keep the project schedule on track. You might even find ways to shorten the project. In our example, if it is decided that it is not important that all the classes are designed before work starts on coding CRUD operations, coding business rules and coding error logging, then all four tasks can be done simultaneously, cutting two days off the critical path. End user training could also be started sooner—let’s say after the GUI is designed—but this task already has slack, so changing the start time will not save any time on the project overall.

If you forget to include a task initially you can add it to the diagram later. Let’s say the task is code DLL’s with a time of 5 Days. Start the line for the new task at the end point of the task on which it depends—in this case designing classes. End the line for the new task at a point at which tasks dependent on it begin—for example, end user training. Examine the current critical path time between these two points to see if the added task will have an impact. Right now, the items on the critical path between the two points are:
  • Code CRUD operations         5 Days
  • Design GUI                          7 Days
  • Create data entry windows    4 Days

                                                                 ______

              Total                                          16 Days

Since the total time for the critical path tasks is greater than the 5 days required for the new task, the new task has slack and will not affect the project schedule. If the new task will take longer to complete than the items on the original critical path, then it forms part of the critical path now and the project schedule is lengthened.

Pros and cons
Although there is theoretically no limit to the number of tasks that can be scheduled using our simple paper and pencil method, things get messy when there are many simultaneous tasks. Also, major changes such as adding a number of tasks can necessitate a total redrawing of the diagram.

On the plus side, CPA can be a "quick and dirty" way to get a project schedule together and keep it on track. It is especially attractive on smaller projects where specialized project management software can seem like overkill or simply is not available to you.

Editor's Picks

Free Newsletters, In your Inbox