1. Womack, James P. and Jones, Daniel T., Lean Thinking, Simon & Schuster, New York, 1996, Introduction, pp. 15–28.

2. Fleming, Quentin W. and Koppelman, Joel M., Earned Value Project Management, Second Edition, Project Management Institute, Newtown Square, PA, 2000, chap. 3, pp. 25–33.

3. Under Secretary of Defense (Acquisition), DoDI 5000.1 The Defense Acquisition System, Department of Defense, Washington, D.C., 1989; and its predecessor instruction: DoD Comptroller, DoDI 7000.2 Performance Measurement for Selected Acquisitions, Department of Defense, Washington, D.C., 1967.

4. Kemps, Robert R., Project Management Measurement, Humphrey's and Associates, Inc., Mission Viejo, CA, 1992, chap. 16, pp. 97–107.

5. Fleming, Quentin W. and Koppelman, Joel M., Appendix I, pp. 157–181 and Appendix II, pp. 183–188.

6. Goodpasture, John C. and Sumara, James R., Earned Value — The Next Generation — A Practical Application for Commercial Projects, PMI '97 Seminars and Symposium Proceedings, Project Management Institute, Newtown Square, PA, 1997.

Chapter 7: Quantitative Time Management

There is no "undo" button for oceans of time.

Tom Pike
Rethink, Retool, Results, 1999

Quantitative Techniques in Time Management

Time management is amply described in most texts on project management. In this chapter we will focus only on the quantitative aspects of time management and make a couple of key assumptions to begin with:

  • The major program milestones that mark real development of business value are identified and used to drive the project at the highest level.

  • The program logic is found in the detail project schedules. Lower level schedules are in network form, preferably the "precedence diagramming method (PDM)" and tie together the various deliverables of the work breakdown structure (WBS).

Major Program Milestones

The first assumption is essential, more so even than the second, because the program milestones tie business value to one of the most essential elements of quality: timeliness. It is almost without exception that the left side (or business side) of the project balance sheet expresses the business sponsor's timeliness needs. In fact, although it is usual to think of the "four-angle" of scope, quality, schedule, and resources as being somewhat equal partners, very often timeliness is far more important than project cost. The project cost is often small compared to overall life cycle costs, but the returns to the project may well be compromised if timeliness is not achieved.

The Program Logic

The second assumption speaks to the PDM diagram, sometimes also referred to as a PERT (Program Evaluation Review Technique) chart, although a PDM diagram and a PERT chart are actually somewhat different. However, suffice it to say at this point that these diagrams establish the detail "logic" of the project. By logic we mean the most appropriate linkage between task and deliverables on the WBS. We do not actually have a schedule at the point that a network diagram is in place; we merely have the logic of the schedule. We have the dependencies among tasks, we know which task should come first, we know the durations and efforts of each task, and from the durations and dependencies we know the overall length of the project. When all of this knowledge is laid on a calendar, with actual dates, then we have a schedule.

Presumably if the project team has scheduled optimally, the project schedule (network laid against calendar) will align with the milestones identified as valuable to the business. If only it were true in all cases! In point of fact, a schedule developed "bottom up" from the WBS task and deliverables almost always comes out too lengthy, usually missing the later milestones. There are many reasons why a too lengthy schedule occurs, but the chief reasons are:

  • The project team members can think of a myriad of tasks that should be done that are beyond the knowledge or experience of the project sponsor. In fact, the project sponsor has not thought of such tasks because the sponsor is thinking in terms of what is required by the business and not what is required to execute the project.

  • Each person estimating their task may not be using expected value and there may be excess pessimism accumulated in the schedule.

The difference between the network schedule and the program milestones represents risk. Such schedule risk in quantitative terms is the subject of this chapter and one of the main management tasks of the project manager. Addressing the risk in time between the requirements of the business and the needs of the project will occupy the balance of this chapter.