# Project Management: Statistical Process Control

for Project Progress Charting

Business Encyclopedia, ISBN 978-1-929500-10-9. Revised 2014-04-23.

An earlier version appeared in *IEEE Transactions on Management.*

By Marty Schmidt

### Abstract

*The Project Management Control Chart (Schmidt Chart)
is a tool for monitoring, reporting, and controlling the progress of
time-critical projects. This project management tool distinguishes
between minor schedule slips and problems that call for serious
management intervention to restore the likelihood of an on-time finish.
Project progress is shown by plotting actual project time used against
the completed critical path percentage. *

*Control
lines in the plotting space signal high or low probabilities of
completing the project on schedule. If an actual progress line crosses a
low probability control line, managers may decide to increase project
effort and resources in order to bring the project back on schedule. On
the other hand, crossing a high probability control line means an early
finish is very likely. *

*The progress plot is
similar to statistical process control charts used in manufacturing
settings. The chart puts current performance into historical
context that can be understood by everyone involved with project
planning and project execution. It serves as a focus for discussion
and real time feedback to the project team, project manager, and
higher management.*

### Contents

• Introduction: A project progress control chart

• Example project progress control chart (Schmidt Chart)

• Monitoring project progress and project completion

• Estimating project task time means and variances

• First analysis: Are you winning or losing project schedule control?

• Statistical control lines for early warning of schedule changes

– Control line method 1: Critical path variances proportional to task length

– Control line method 2: Individual critical path variances

– Control line method 3: Risky non-critical path tasks

• Building and using the project progress schedule control chart

– User input: Project task time estimates, expected values, and variances

– Plotting data for project progress baseline and statistical control lines

– Plotting actual project progress

## Introduction: A project progress control chart

This article presents a tool for monitoring, reporting, and controlling the progress of time-critical projects. The "progress chart," built from standard PERT network data, gives project managers the kinds of statistical process control over project progress usually associated with process control charting and a manufacturing process. It provides:

- Simple visual project monitoring, comparing current actual progress to planned or expected performance.
- A clear distinction between tolerable deviations from plan and unexpected developments that call for management intervention.
- An easily interpreted progress status report for higher management and the project team.
- A simple means for comparing different projects with respect to planning accuracy.

During time-critical projects—developing new products for a highly competitive market, for instance—strong interest centers on the likelihood of finishing on schedule. Accurate and current information on progress relative to schedule may be crucial for the scheduling of IT resources, engineering work, manufacturing operations, product announcements, and customer shipments. In fact, project finish time is usually a very high priority in many kinds of engineering projects, product research projects, or software development and all kinds of IT projects, because a late finish or an early finish may have major economic and other business consequences.

Once a project is underway, however, the probability of finishing on schedule is not easily read from PERT or GANNT charts. This control chart (progress chart) shows these probabilities at a glance.

Project management research suggests that project schedule goals are more often met when:

- Project managers, line managers, and high level managers all participate in goal setting and project scheduling.
- Managers use both formal and informal project monitoring mechanisms.
- Managers provide timely and well-targeted responses to project progress problems.
- Groups collaborating on projects maintain a high level of communication within and between groups.

On projects where the most critical project management goals are schedule goals, the progress chart serves effectively to focus all of these activities.

For a working example, see Project Progress Pro, an easy-to-use Excel-based tool, available online for implementing statistical process charts as described below.

## Example project progress control chart (Schmidt chart)

Figure 1 shows a progress chart tracking actual progress and planned progress for a completed project.

- The horizontal axis represents time since project start. Original project scheduling expected a project start at
and a finish at planned completion time**t**_{0}. Time**t**_{PC}is the critical path (CP) time from a task/event network such as a PERT chart.**t**_{PC} - The vertical axis represents project progress as a percentage of the CP (as explained below).

Had this project gone as planned, actual progress would lie on top of the
original plan baseline, reaching 100-percent completion at *t*_{PC}, 32.5 weeks. Instead, actual completion time* t_{AC}*.
was 39 weeks. Filled circles are planned critical
path events, open circles are actual event occurrences. Solid
lines between circles show a continually increasing
discrepancy between actual and planned progress.

Control
lines warned, early in the project, of a probable late finish. The
first warning came about 8 weeks into the project, when actual
progress crossed the control line for probability ** p**< 0.25. This was an early signal that the project now had only a 0.25 probability of finishing at

*t*_{PC}of 32.5 weeks. The second warning came at about 18 weeks, when actual progress crossed the

**p**<.01 control line. Here is a clear alert, just a little more than halfway through the planned project time, that the probability of an on time project finish was now only 0.01 or less. This was a strong message that management should now either (a) simply expect a late finish, or (b) apply additional resources and effort to raise the probability of an on time finish.

Note that all segments of the actual progress line slope *less *than
the baseline, showing that management consistently underestimated task
times. However, the smoothness of the progress line shows that progress
was relatively continuous and that the expected critical path was in
fact the actual critical path.

This project very likely secured approval and project funding with the support of a project business case analysis, weighing expected costs and business benefits from the project against expected results under other projects or under "business as usual" (not undertaking the project). A key assumption in this business case, no doubt, was an expected on time finish. Now, before committing more funds and resources to raise the likelihood of an on time finish, management will want to see another project business case comparing costs and benefits from an on time finish with costs and benefits expected under a late finish.

## Monitoring progress and project completion

In business projects, no single metric adequately represents project "progress" for all purposes. Different progress measures might reflect the current percentage of ...

- Design problems solved
- Design phases (or stages) completed
- Budgeted person/hours used
- Allocated funds spent

Other measures can also be used. However, if project completion date is a major concern, we* *can
represent the project with a single path, a series of consecutive
non-overlapping tasks, where current progress is a point on the
path. Figures 2 and 3 show how this path derives for the progress chart
from a PERT chart analysis. For the progress chart, project progress is
measured as:

- Percentage of total critical path time used.

Figure
2 below is a top level PERT network for a new product development
project. Numbered circles are events and arrows are tasks leading
from event to event. Starting event #1, for instance might be "Product
Requirements Defined" and final event #15 might be "First Customer
Shipment." Other top level CP events could be "Logic Design Specs
Completed," "Simulated Timing Verified," "Prototype Assembled," and so
on. For complex projects, managers will also use lower level plans of
activities and events that make up each task on the top level plan.

Figure 2. The PERT activity/event network for example calculations. Events are circles, tasks are arrows. Heavy arrows and blue circles represent the critical path for this project.

Measures of project progress focus on the critical path through this network, the path from events 1-4-7-11-14-15.

## Estimating project task time means and variances

Figure
2 also shows the expected completion time and variance for each
task, in weeks (variances are in parentheses). These come from standard
PERT methods: if * t_{i,j}* is the task time from event

**to event**

*i***then the expected task time,**

*j*,**(**

*E***) and the estimated variance of the task time probability distribution**

*t*_{i , j}

*are estimated as:*

**σ**^{2}_{i,j}Equation 1 |
longest possible task time b =.most likely task time. m = | |

Equation 2 |

These estimates (shortest, longest, and most likely task times) are the product manager's "input data" for the progress chart. They provide a basis for measuring project progress and for locating the control lines shown in Figure 1, that signal likely early or late project completion. Conclusions about likely project schedule slips or early finish depend on the validity of these three estimates See the section Building and Using the Project Progress Chart for more on these estimates as input data for the chart.

Statistical note: *E( t _{i,j} ), *the expected task time estimate for task

*, can differ from the project manager's "most likely" task time assumption*

**i, j****m**in the equations above.

**xpected task time**

*E*

**E**(**) is the mean**

*t*_{i, j}**(**

**) of the task time probability distribution, derived from**

*μ*

*a**,*

*b**,*

**and**

**. The estimated most likely task time (**

*m***) is the modal task time value in that distribution**

*m*

**.**In task 1,4 for instance, the product manager estimated ** a** = 3.6, **b** = 7.5, and **m** = 5.6 weeks. The resulting expected task time is 5.6 weeks and the variance is 0.422 weeks.

- Expected task times are the basis of the progress plot's original plan baseline.
- Task variances make possible control lines (following sections).

## First analysis: Are you winning or losing project schedule control?

In
the Figure 2 example, analysis of the expected task times reveals a
32.5-week CP linking events 1, 4, 7, 11, 14, and 15.
Figure 3 below shows the CP by itself with an * E*(

*t*_{i,,j}) for each CP task along with a percentage figure for the task contribution to the total CP. The progress chart framework is built from these data.

Figure 3. Project critical path events (blue circles) and tasks (arrows) for the progress chart. The project manager's estimated most likely task times are added together to make 100% of the expected project duration.

In the progress plot, horizontal axis segment *t _{0}* –

*t*spans the total expected CP length (here, 32.5 weeks = 100%). The vertical axis runs from 0 to 100 percent. The original plan line baseline runs from lower left to upper right, from point (

_{PC}*t*

**, 0 percent) to point (**

_{0}*t*, 100 percent). Critical path events appear on this diagonal line (the filled circles in Figure 1).

_{PC}Actual project progress is tracked by plotting:points located as:

- The actual completion times of CP events, as total time after
(horizontal axis) and ...*t*_{0} - The original CP percentages for those events (vertical axis).

Actual progress event completion points are open circles in Figure 1.

Figure 4 below shows the progress chart histories of four projects. The charts reveal discrepancies between plans and actual completion times.

By contrast, the actual progress line for Project illustrates consistently underestimated (under planned) task times. Project B, like the project in Figure 1, gave indications of a late finish from the start. BProject C's
actual progress line shows the effects of overestimating some task
times and underestimating others. The extent to which the actual
progress line deviates from or "hugs" the original plan line represents
planning accuracy.The Project
actual progress line shows what happens when tasks off the
original critical path take longer than planned and become CP
tasks. This kind of planning problem makes horizontal line segments
in the actual progress line (there is a real time gap between the end
of one original CP task and the start of the next).D |

Actual progress lines of several projects, current or historical, can be plotted together by scaling the horizontal axis as "Percentage of Original CP Time Actually Used" instead of absolute time.

## Statistical control lines for early warning of schedule changes

The original plan and actual progress lines are descriptive statistics, easily calculated without reference to any special knowledge in statistics. Actual time used is simply compared to planned usage. These lines can be derived without a full PERT network: "phase transition points" or some other locally used series of planned and actual event dates will suffice, as long as the sum of the segments equals planned project length.

The control power of the progress chart is enhanced if task time variances are used to make probabilistic inferences about actual project completion time. As shown in Figure 1, these follow when actual progress crosses a control line. Crossing the line is a warning that the project has a new probability of either finishing early or finishing late.

*Unfortunately, the explanation of statistical control lines is necessarily somewhat ...* statistical.

*The statistical theory is elementary, but even that can deter those who are uncomfortable with the subject. However, the calculations for locating control lines on the progress chart are very simple and easily applied by rote. Their intelligent use requires just a conceptual understanding of the three sentences in the previous paragraph.*

*The statistical theory is here for the sake of completeness. **Those interested primarily in building and using the chart may wish to skip directly to the practical guidance in under Building and Using the Project Progress Schedule Control Chart.*

Each control line is associated with a probability ** p, **the probability of project completion on or before

*. Control lines for any number of*

**t**_{PC}**values between 0 and 1.0 may be calculated, but the plot is clearer if only a few are plotted, e.g., for**

*p**= 0.01,*

**p****= 0.25,**

*p**= 0.75, and*

**p***= 0.99.*

**p**Note that the original plan baseline is also the** p**
= 0.50 control line. An actual progress line below baseline signals a
probability less than 0.50 of on time finish. An actual progress
line above the baseline implies a greater than 0.50
probability for finishing on or before planned completion
time.

The location of control lines depends on several assumptions about project task times. Five assumptions underlie all control line methods. These five are usual in PERT analysis:

- Assumption 1: Estimated Task times are independent. Actual time used for any task has no effect on estimated task time or variance of any other task.

- Assumption 2: Probability distributions for task times have means and variances given by the equations 1 and 2 in the section Estimating Project Task Time Expected Values (Means) and Variances.
- Assumption 3: Probability distributions for the sums of individual task times are approximately normal (Gaussian) with means and variances as follows:

Equation 3 | |

Equation 4 |

Assumption 3 means that the Central Limit Theorem applies to sums of expected task times. Thus, no other assumptions are needed about the shapes of individual task time probability distributions, where interest centers on task time sums.

- Assumption 4: Estimated completion time for the project equals the sum of estimated critical path task times. Thus, the original plan line shows each CP task ending at the next task's beginning.
- Assumption 5: During the project, estimates for
,**a**, and**b****m**(estimated least possible task time, longest possible task time, and most likely task time) for each task do not change. - When the actual progress line crosses a control line, e.g., the
= 0.25 line, the probability of completing the project by**p**or sooner is 0.25, as long as the original**t**_{PC}**a**, and**b***m* - However,
if the manager now deviates from the original plan—applying more or
less resources than originally planned for a specific task, for
instance—the original control line probabilities are not valid during
that task. Should new control lines be drawn when resources are shifted,
or when estimates
,**a**, and*b*otherwise changes? If the changes represent corrective actions for one CP task, to get the project "back on schedule," the original control lines should remain. They will apply again when the "unusual" task is completed.*m* - If, however,
,**a**, and**b**estimates change for several CP tasks, new control lines should be drawn, since the old ones will not be valid again. And, if changes in**m****a**,**b**, and**m**during the project alter the CP itself, the original plan line may stay in place, as far as it represents completed tasks, and a revised original plan line can be drawn to the new point (, 100 percent).**t**_{PC}

Given Assumptions 1-5, we can choose one of several methods for plotting control lines. So as to contrast the different methods, each is illustrated with the data from the Figure 2 Project PERT chart .

### Control line method 1: Critical path variances proportional to task length

The simplest approach to control lines may be called the proportional critical path variances
method. Most users will use this approach most of the time, not
only because it is simple, but also because the additional
assumptions it requires are usually quite reasonable. The proportional
CP variances approach may be used if two more assumptions are accepted:

- Assumption 6: The likelihood of non CP tasks intruding on the CP is so small that only CP tasks need be considered when constructing control lines.
- Assumption 7:
Variances of individual task time probability distributions are
proportional to task length. Individual task time variance estimates
(which may or may not conform exactly to Assumption 7) are used only to
obtain an estimated variance for
*total*project completion time. This variance is then "redistributed" among individual tasks as if Assumption 7 were true.

If Assumptions 6 and 7 are not tenable, one of the control line methods in the following two sections should be used instead.

Figure 5 shows how control lines are drawn under control line method 1, the "Proportional CP Variances" method.

Figure 5. Plotting points for placing control lines in the progress plot. See text for explanation

Here, each control is a straight line from a point on the horizontal (time) axis, point ** t_{X}**, 0 percent on the vertical axis, to the project end,

*t*, on the horizontal axis and 100 percent on the vertical axis. For the control line at probability

_{PC}*p*= x, the value of

*t*is computed as

_{X}* t _{X}* =

*z*√ σ

_{X}^{2}

_{T }Equation 5

where

*z*is the horizontal axis value under a unit-normal distribution, above which proportion_{X}*X*of the distribution lies.*σ*is the sum of the all individual task variances (Equation 2), that is:^{2}_{T}

*σ ^{2}_{T}* = Σ

*σ*

^{2}_{i,,j }*for all tasks i,j on the critical path.*

Note that *z _{X}* values can be taken from a unit-normal table or produced with calculator or spreadsheet functions that deliver unit-normal z values for given probabilities. Unit-normal

*z*values, of course, are determined entirely by the probability requested. For probability

*x*= 0.01, for instance,

*z*= 2.326 and for

_{X}*x*= 0.25,

*z*= 0.675.

_{X}The value of *σ ^{2}_{T}* follows entirely from the values of

*a*and

*b*that are estimated for each task on the CP (

*a*is estimated shortest possible time for a task, and

*b*is estimated longest possible time). Equation 2 above produced the variance in weeks (individual

*σ*) for each task, as displayed on the task lines in Figure 2. For the PERT network in Figure 2, the overall critical path variance in weeks is the sum of these:

^{2}_{i , j }* σ ^{2}_{T}* = 0.422 + 0.490 + 1.361 +1.440 + 1.480

= 5.193

And, for probability* x* = 0.01:

*t _{X}* = (2.326) √ 5.193

= 5.30. weeks

Similarly, for probability *x* = 0.25:

*t _{X}* = (0.675) √ 5.193

= 1.54 weeks

Control
lines for probabilities greater than 0.50 lie above the original plan
baseline, intersecting the vertical axis at some value greater than 0
percent. The horizontal axis coordinate of these is found, as Figure 5
suggests, by extending the axis to left of ** t_{0}**, where negative values represent an actual start before planned start at

**.**

*t*_{0}From the unit-normal distribution, all ** z** values for control line

**values greater than 0.50 will be negative. From the unit-normal distribution's symmetry, note the following:**

*p** t _{1.0 - X}* = –

*t*Equation 6

_{X}### Control Line Method 2: Individual Critical Path Variances

If task time variances are clearly not proportional to task lengths Assumption 7 is not tenable and control lines should be drawn by the method of individual critical path variances. A project manager would make this judgement, for instance, when the project plan and critical path include some tasks that will certainly have very small variances (task length is known with high confidence), while other CP tasks have quite large variances, unrelated to overall task length.

The individual CP variance approach for placing control lines in the progress chart requires Assumptions 1-6, and a new assumption:

- Assumption 8: Probability distributions for individual tasks on the top-level PERT CP are approximately normal (Gaussian).

Assumption
8 is reasonable if each task on the top-level PERT represents the sum
of a series of tasks from a lower-level PERT. This method is identical
to the preceding, except that a new *t _{X}* is
calculated at each original plan CP event. The total variance at each CP
event is taken as the sum of the remaining task variances. Equation 4
is applied at

*each*CP event, except that

*σ*(in the equation) now represents

^{2}_{T}*all remaining*CP tasks.

Figure 6 shows the resulting progress chart with * x* = 0.01 and

*= 0.99 control lines.*

**x**Figure 6. Two control lines for the progress chart, constructed with the method of individual critical path variances. The horizontal locations of control line plotting points are calculated as offsets from the original plan baseline.

With the example data and * x* = 0.01, for instance,

**= 5.30 weeks at project start (as before). At the next CP event, 4,**

*t*_{X}*for the remaining CP is 5.193 – 0.422 = 4.771 and*

**σ**^{2}_{T }**is thus**

*t*_{X}_____

**= (2.326)**

*t*_{X}**√**4.771

= 5.07 weeks

A

**is calculated in this way for each CP event through the next to the last (here, event 14); the control line is offset horizontally by this amount from each of these events.**

*t*_{X}### Control line method 3: Risky non-critical path tasks

Engineering projects—especially those composed of several nearly independent sub-projects—are sometimes characterized by parallel and relatively independent activity paths which only meet at a few "nodal" events (such as "Prototype Assembled"). As long as Assumption 6 is tenable, however, critical path progress adequately represents progress for the whole project.

However, when task time variances are large relative to expected task times, and when one or more non CP paths have a large variance, the manager may want to recognize non CP risks in the progress chart. This section presents an approach to control line placement in the progress chart that makes this possible.

Unfortunately, calculating expected task lengths and risks so as to reflect the entire PERT network becomes a prohibitively complex and assumption-laden undertaking in networks with more than a few events. For progress plotting and control line purposes, however, it is usually satisfactory to apply some elementary probability rules in order to recognize just one or a very few especially risky non CP tasks intruding onto the CP. Figure 7 illustrates the approach.

Figure 7 Including non critical path risks in control line calculations. (* a*) Two path segments considered in the example. (

**) Time relationships in both segments. (**

*b***) Probability distributions assumed for path segments immediately after event 11.**

*c*Consider, for instance, the project plan portion shown in Fig. 7(a), covering events 11, 12, 14, and 15 from Figure 2. The project's CP links events 11-14-15. The expected length of this CP segment is 9.2 + 6.4 = 15.6 weeks. Note that non CP path segment 11-12-15 is nearly as long: 8.8 + 6.2 = 15 weeks. The 0.6 week difference between path segments may be thought of as "slack" time in the 11-12-15 segment.

Consider also the standard deviations (*σ*) for each of these segments: both segments have task time *σ*s that are large relative to the 0.6-week difference between paths:

σ of path 11-12-15 = √1.174 + 1.250 = 1.557 weeks

σ of path 11-14-15 = √1.440 + 1.480 = 1.709 weeks

The near critical nature of path 11-12-15, and the large size of these σ's relative to the slack in path 11-12-15, suggest that control lines should reflect both path segments in Fig. 7(a). We may include the risk of path 11-12-15 entering the CP by invoking Assumptions 1-5, 8, and one new assumption about the placement of slack time in segment 11-12-15:

- Assumption 9: Each non CP task that contributes to the progress chart will begin at the earliest possible time.

As
the time lines in Fig. 7(b) suggest, Assumption 9 puts all the slack in
segment 11-12-15 at the end of task 12-15. Other assumptions about
slack are possible, but some assumption has to be made in order to
proceed. For each control line probability x, the *t _{X}* horizontal axis "offsets" from the original plan line will now be calculated for each event, 11, 12, and 14.

Consider the situation after event 11. Each control line probability *x* represents:

* x* = *p* [(Path 11-12-15 __>__ 15.6) OR (Path 11-14-15 __>__ 15.6)] Equation 7

In general terms, if we let

*A* = the event (Path 11-12-15) __>__ 15.6), and

*B* = the event (Path 11-14-15) __>__ 15.6)

then

**p**(A or *B*) = * x*, the control line probability.

Assuming that A and *B* are independent events (Assumption 1), elementary probability theory gives

*x* = *p*(*A*) + *p*(B) – *p*(*A* AND *B*) Equation 8

where

*p*(*A* AND *B*) = *p*(*A*) *p*(*B*)

Figure
7(c) shows probability distributions for total task time in both path segments. The distribution for non CP path 11-12-15 has expected value *μ _{1}*= 15.0 and

*σ*= 1.557. The comparable distribution for CP path 11-14-15 has expected value

_{l}*μ*= 15.6 and

_{2}*σ*= 1.709. From Assumptions 3 and 8, both distributions will be described as

_{2}*f*(

*z*), the standard unit normal distribution:

*f *( *z *) = ( 1 / √ 2*π *) *e ^{– ( t² / 2) }*

*Equation 9*

^{ }The total area under *f*(*z*) from *z* = – ∞ to *z* = + ∞ equals 1.0, and the probability that a value of random variable z falls within any interval on the *z* scale is the area under the curve, over that interval. In the 11-14-15 distribution, a *t _{X}* can be converted to a unit-normal z value as:

*z*_{2} = *t _{X}* /

*σ*

_{2 }Equation 10

In the 11-12-15 distribution, the same *t _{X}* value as a unit-normal

*z*value given as

*z*_{1} = ( *t _{X + }*

*Δ*) /

*σ*

_{2 }Equation 11

where *Δ* = *μ*_{1} – *μ*_{2} (i.e., slack in segment 11-12-15). Then, from Equation 8 and Assumptions 1–5,8, and 9, a control line for probability* x*, at event 11, will be offset horizontally from the original plan baseline by an amount

**where probability**

*t*_{X}*is described as follows:*

**x**Equation 12

Given a control probability *x*, Equation 12 converts to a *t _{X}*
by Equation 10 or Equation 11. In practice, however, the fastest route
to a solution may come from trial and error calculations, starting with
proposed

*t*values and finding the associated

_{X}*x*s. Using the above method at event 11,

*t*for

_{X}*x*= 0.01 is 1.75 weeks (as opposed to 3.97 weeks, when path segment 11-12-15 is not considered).

Figure 8, below, shows the *p*
= 0.01 control line through a section of the progress chart
plotting space. The same control line is shown located as described
here, but also as located by Method 2, in which the 0.01 control line ignores path 11-12-15.

Figure 8. Comparison of ** p **<
0.01 control lines, one representing only critical path risks and the other including risks for CP and non CP path segments located in the progress chart with Method 3.

Note
that the original plan line now shows planned completion of event
12, a non CP event, at 79.1 percent of the CP (where it would fall given
an earliest possible start). Control line offsets *t _{X}*
are calculated at events 12 and 14 just as shown above, except that the
means and variances of both probability distributions are reduced
appropriately

One conclusion from this demonstration of control line method 3, is that the presence of very risky non critical path tasks reduces the margin for error in project schedule planning, that is, the project manager is allowed less schedule "slippage"before the probability of an on time finish drops substantially.

## Building and using the project progress schedule control chart (Schmidt Chart)

Progress charts are typically built for project control and
reporting purposes by those who create the original project plan—usually
the project manager responsible for project planning, project** **execution, project
outcomes, and securing project funding. This individual is
usually the best prepared person to supply the progress chart input
data, the task time estimates. Schmidt charts are also built and used,
however, by those in Project Management Offices (PMOs) responsible for
project portfolio management, business analysts in budget offices, Line
Managers who supervise project managers, and anyone else who has a stake
in on-time project completion.

All of the statistical theory notwithstanding, the project progress schedule control chart (Schmidt chart) is easily produced from a few simple data. All that is required in order to build and use the control chart, as illustrated above, are:

- The project described as a sequence of non overlapping tasks and task-end events. Examples above used critical path tasks from a project PERT network, but a PERT analysis is not necessary for creating and using the progress chart.
- Estimates of task times for each task in the project task sequence. Estimates needed are: The longest possible time (
), shortest possible time (**b**), and most likely time (**a**).**m**

### User input: Project task time estimates, expected values, and variances

Table 1, below shows the project manager's original estimates for ** a**,

*, and*

**b****, for each CP task from the example project discussed above. This is the progress chart's initial user input, shown here in blue cells.**

*m*

Table 1. The project manager's initial assumptions, or estimates, of tasktimes appear in the blue cells under headings for —the shortest possible atask time, —the longest possible task time, and bm—the most likely task time. These values are used to derive an expected task times (E t_{i , j} ) and a task time variance ( ) for each task as explained in the text.σ²_{i , j } |

The expected times and variances from Table 1 (yellow cells) are then used to create plotting data for the original plan baseline and control lines. For Table 1:

- The expected time
*E*(*t*) in each row is calculated from_{i , j}*a*,*b*, and*m*in that row using Equation 1. - Variance
*σ²*in each row is calculated from a and b in that row using Equation 2._{i , j}_{ }

### Plotting data for project progress baseline and statistical control lines

With expected times and variances in place, the rest of project progress chart plotting data can be completed as shown with Tables 2a and 2b. (Figures 1 and 5 were plotted by Microsoft Excel directly from Tables 2a and 2b, using the Excel's scatter chart with straight lines.

Table 2a.
Plotting data for example progress charts in Figures 1 and 5. Data for
control lines and base line are derived from the expected task times and
task time variances in Table 1 above (rightmost two columns in Table
1), using Equations 4, 5, and 6, along with standard source unit normal z
values for the Gaussian distribution |

Table 2a data serve as plotting coordinates for the original plan baseline and four control lines shown in Figures1 and 5. Their vertical axis coordinates appear in Column (f):

- The events and tasks in Columns (a) and (b) are simply names for horizontal axis points that will be plotted.
- Columns (c) and (d) hold the expected task times and task time variances for each critical path task, taken from Table 1.
- Column (e) values are estimated task times from Column (c) expressed as percentages of total critical path
- Column (f) (green cells) holds vertical axis coordinates for all lines plotted in the progress chart. These are cumulative totals of task time percentages in column (e).
- Columns (g) - (k), yellow cells, are the horizontal axis coordinates for plotting the original plan base line and control lines,
- The original plan base line is plotted from vertical axis coordinates in Column (f) and horizontal axis coordinates in Column (i). The baseline Column (i) coordinates are the cumulative task times at each event, added from expected task times in Column (c).
- Column (f) has the vertical coordinates for all control lines. The horizontal coordinates for control lines may be calculated in several different ways depending on the control line method is used , (Method 1, Method 2, or Method 3). The
simplest and most commonly used approach is Method 1, as
illustrated in Table 2a, Figures 1 and 5, Under Method 1,
each control line's horizontal position at any task
*i,j*end is:

Horizontal position = Control line horizontal axis starting point

+ distance covered towards end point

For a control line at probability* X*, at the end of task *i, j*, ...

Horiz. position = *z _{X}* √

*σ²*

_{T}+ (% CP Completed)(Total CP Length +

*t*) Equation 13

_{X}where

*z _{X}* = Unit normal

*z*where the probability of exceeding

*z*is

*X*

For control line probabilities illustrated in this example,

F

*z*= –2.326

_{0.99}*z*= –0.675

_{0.75}*z*= 0.675

_{0.25}*z*= 2.326

_{0.01}* σ² _{T}= *The sum of individual task variances (Column (d) total)

% CP Completed = Percentage of CP completed at end of task *i, j* from Column (f)

Total CP Length = The sum of individual expected task times from Column (c)

* t _{X}* =

*z*√

_{X}*σ²*

_{T}Applying Equation 13 to the control line for *p* <.01 at the end of task 7,11 (Event 11), where 52.0% or 0.52 of the CP is completed (Column (f), the horizontal axis coordinate of 19.44 weeks is:

Horiz position = (2.326)(√5.193 ) + ((0.52)(32.5–(2.326)(√5.193 ))

= (2.326)(2.279) + (0.52)(32.5–5.301)

= 5.301 + 14.144

= 19.44

Examples in Figure 1 and Tables 2a and 2b represents control line charting under Control Line Method 1. When assumptions about task time variances and non critical path tasks warrant the use of Control Line Method 2 or Method 3, however, horizontal placements of some control line points may differ from those under Method 1. In these cases, horizontal placement of control lines at each task end is calculated as a horizontal offset from the original plan base line, as illustrated in Figures 6, 7 and 8.

### Plotting actual project progress

Actual project progress can be plotted only after project execution begins.

- For the actual progress line (as in Figure 1), vertical axis coordinates are the same as the corresponding vertical axis coordinates on the original plan baseline (from Column (f) of table 2a above). These coordinates appear again in Table 2b, below.
- Horizontal coordinates of the actual progress line are in blue cells of Column (j) in Table 2b below. Each is the total elapsed time since project start at
*t*up to the task-ending event. Column (i) holds the actual time for each task. Total elapsed times in column (j) are built from the column (i) data._{0}

Table 3. Plotting points for the project's actual progress line. These points are added as soon as each actual task time is known. |

**Project Progress Pro:**

An easy-to-use Excel-based tool, available online for implementing statistical process control charts for project management.

By Marty Schmidt. Copyright © 2004-.