The Database Design Resource Center

PERT CHARTS : Project Network Diagrams

I. Pert Charts - Background

As project managers, we are notorious for always demanding more, and seem never content with the quality and quantity of resources made available to us.

Having satisfied ourselves that no further allocation is forthcoming, we then proceed to wring out the maximum possible out of whatever has been laid before us – in terms of manpower, material and money. Our aim is to complete the project on schedule, of course. Our motivation? Not having to rush against deadlines, or end up facing flak for exceeding the budget or slipping on delivery schedules.

This is where PERT charts comes into play.

II. PERT Charts Defined

PERT, short for Program Evaluation and Review Technique, is a tool that came out of the crucible of the Polaris Missile Project development process. Like Gantt charts, PERT too is a chart – only, there are no rows and columns like the former.

For each task that goes into building a project, the project manager lists all resources that shall be required to complete it alongside. These tasks are arranged appropriately along a timeline. Some tasks are to be handled concurrently, others overlap, and a few have dependency relationships with other tasks.

Milestones are an inherent part of the PERT chart, and are pin-pointed upfront, rather than as an afterthought. Project reviews, which can take from 15 minutes to a fortnight depending on the complexity of project, are milestones themselves, and may be given due place on the chart. These are called “nodes” in PERT terminology, while activities that are required to be carried out to achieve a milestone are symbolized by arrows called “vectors”.

All nodes are connected by vectors; you should ideally not find any node which is isolated. The start node of the project is the only node from which vectors only emanate, while the end node of the project is the only node into which vectors only terminate. The direction of the vectors indicates the sequence of activities; usually the diagram is drawn such that the overall direction is from left to right.

The overall PERT charts thus created give the appearance of a “network”, hence this chart is also popularly known as “network diagram”: (This is just another view of the Gantt chart in another article):

Pert Charts

Each vector is associated with a standard set of information – the name of the activity being processed, expected time required to complete the activity, the number of team members involved in it, and the activity leader’s initials.

It is possible that there exist vectors that are free from any resources – there is no real activity involved. They are called dummy vectors, and are just there to not make the network appear disjointed.

III. The Critical Path

Often, it is the subtle things in a game, such as the position of a pawn on the chessboard, which can change the flavor of the game. In projects, the best of plans and resources can go haywire if certain tasks are not given utmost care. Unfortunately, these are the very tasks that sometimes get overlooked.

The beauty of PERT charts is that it turns the project manager’s attention to such tasks, by way of Critical Path. Simply put, it is the node -> vector -> node -> vector … chain or path of the diagram, whose total time of completion is the longest. If your PERT chart is ready, then simply:

  • List the different paths from the start node to the end node, using the (node) -> (vector) -> (node) notation.
  • For each path, compute the total time taken to reach from start node to end node, by summing the time for each of its vector.
  • The path with the maximum total time is the Critical Path.

By implication, all activities lying on this path are critical activities; which if given less importance than deserved, can give the maximum headache. Below is a (zoomed out) example:

Pert Charts

What we have enumerated above is a very over-simplified method of computing the Critical Path, in order to demonstrate its meaning. In reality, there is another dimension associated with “time for an activity”. This dimension brings some fuzziness in computation of time.

Who said life comes in only two colors – either pitch black or sparkling white? Fuzziness brings in the element of gray, and represents the uncertainty of when an activity can really, really begin and when it can really, really end; our best intentions notwithstanding.

So, instead of saying that activity M will begin at 8:40:23 on 16th October, and end at 16:39:03 on 11th November, we quite tactfully state that:

  • It is possible that activity M may start earliest by, say, 14th October (T-ES).
  • It is possible that this activity may end earliest by, say, 9th November (T-EF).
  • It is possible that this same activity may end latest to latest by, uh; say 20th October (T-LS).
  • Ahem, given the uncertainty, I would say that it might take by 15th November to finish this particular work (T-LF).

You can see the tug-of-war between optimism and pessimism here. For each activity, therefore, there is a “slack time” involved,
which is = T (LF) – T (EF).

Coming back to the critical path, you will notice that all vectors on this path will have zero slack time. This means that each such activity has to complete by the scheduled time: any slippage, and prepare yourself for flak.

Once the project commences, real-time data about activity progress start pouring in, and we have to keep comparing the actual time, money and manpower being consumed in each vector against their corresponding estimated values. This fine-tuning is an ongoing job, and continues till the end node has been reached.

Each deviation from estimated values not only changes the contour for that particular activity, but it also has a domino effect on other in-progress and pending activities as well.

It might also be revealed that a vector that appeared to be on the critical path is not at all so, while a vector that we were complacent about in the design stage, all of a sudden becomes critical!

IV. End word

PERT charts have been implemented on the computer quite elegantly. Sophisticated softwares provide you with calculations of slack times, bring out the critical path very graphically on the screen, and also keep updating it whenever you feed in the real-time data as work progresses.

All in all, if PERT charts are handled properly, we can rest assured that there is at least a modicum of control over the progress of the project.

Return to Software Project Management

Exclusive interviews with:
Steven Feuerstein, PLSQL expert
Donald Burleson, Top IT consultant

Free eBook

Subscribe to my newsletter and get my ebook on Entity Relationship Modeling Principles as a free gift:

What visitors say...

"I just stumbled accross your site looking for some normalization theory and I have to say it is fantastic.

I have been in the database field for 10+ years and I have never before come across such a useful site. Thank you for taking the time to put this site together."

Mike, USA

Read more Testimonials

Database Normalization eBook:

Database Normalization eBook

Copyright © / Alf A. Pedersen
All rights reserved.
All information contained on this website is for informational purposes only.
Disclaimer: does not warrant any company, product, service or any content contained herein.

Return to top

Copyright acknowledgement note:

The name Oracle is a trademark of Oracle Corporation.
The names MS Access/MS SQL Server are trademarks of Microsoft Corporation.
Any other names used on this website may be trademarks of their respective owners, which I fully respect.