Asking the Right Questions of the Team

In the last article, we saw how the analysis of project problems mirrors quite well the situation a doctor is confronted with. We took our cue from this and developed a diagnostic approach toward project control. We saw that there were four broad types of problems, each reflecting a commonly found situation. In order to determine which of these types are responsible for the problems we might be seeing, we need to formulate a precise set of questions.

The situation as a task begins is shown as follows. This assumes that it has not been delayed by problems in predecessor tasks. The dark bar shows the original forecast, now elevated to the status of the 'Plan" or 'Baseline'. The upper bar continues to be the current best forecast.

As this task continues we should be tracking its progress. Thus the first question we ask our team at each update period is:

"How much progress has been achieved to date?"

Percent Complete
This question is usually answered in the form of a percentage. Now there are many interpretations of what a percentage can mean but let us be quite clear about this: The only meaningful measure is one that which provides a description of output as opposed to input - to some degree of approximation. We do not want our team to tell us they are 50% complete because half of the time (an input measure) has elapsed. We do not need help with this quantity from anyone. Similarly, we don't want to be told that 50% has been achieved because half of the allotted hours of effort have been consumed.

We are interested in a measure of progress toward completion. Of course this implies we know what completion is. This can only be the case if we had a clear and shared understanding with the team as to what the deliverable (which defines 100%) of this task is. This is a vital part of the planning and one that cannot be ignored if progress measures are to mean anything.

So, a percentage measures something physical. This is not always easy. In work involving research, design, writing, software development and similar activities, this is quite elusive. In work relating more closely to the visible and physical world, measures are easier to find.

In any event we should not claim too much precision in this. Percentages expressed to the nearest decile are probably already exceeding the kind of precision that can be claimed for them. In difficult situations we might limit our team to a report of 0, 50, 100, where 50 is only reported when they genuinely think that they are more than half way. Only when they are finished may they claim 100%. This method has the merit of being conservative.

Let us assume then that we have a relatively objective measure of output.

Comparing with Time
Clearly our measure cannot mean very much in the absence of something of input against which to compare the percentage of output achieved. The obvious comparative measure might be time elapsed. Therefore, were we to find that we are 50% complete with 70% of the time allotted for the task elapsed, this begins to tell us something and it is probably (though not definitely) not good news.

In order to determine the reason behind such figures, we need to ask more questions. And these questions are guided by the SEAM method we saw in the previous article - i.e. the four types of reason why tasks fall or appear to fall behind.

Type 1. Asking About the Possibility of Start Delay
One of the reasons might just be that we started late on this task (relative to the baseline). Clearly then, we simply need to address to the team the question:

"When did you actually start?"

The answer might indicate the following situation:

In this situation it is clear that the lower-than-expected progress report is due to the later-than-expected start date.

We should also ask about 'Actual Finish' in cases where the task has finished and 'Forecast Finish' in cases where it has not.

To summarise, the questions we have collected so far are:

· Progress (a percentage)
· Actual Start Date
· Actual or Forecast Finish date

If the actual start did not lag behind the planned (baseline) start, then there are three other reasons to explain it. The situation then looks like this:

We need to determine the reason for the gap between expected and reported progress.

Type2. Asking about Absence
The reason for the low progress figure could be related to the unexpected absence of some resources from the job - i.e. not getting the input hours promised by the team. The question to ask here is simply,

"How many Actual Hours were expended so far?"

Type 3. Asking about Efficiency
The most common reason behind slow progress is related to a low 'production' rate, whose cause we must identify. Here we mean that there are factors retarding the rate of production, at least as compared to our baseline figure.

Candidates could include work resistance, lower than expected skills, poor morale or attitude, adverse conditions - all of which reduce to a poor estimate of the work. The questions to ask here are:

"What problems have been encountered?"
"What is the current forecast date of completion for this task?"
"What is the current forecast for effort (hours to be worked) on this task?"

Some analysis will be required on the part of the project manager to determine the average number of hours expected to be worked per day and the nature of the calendar over the time this task will occur. This must agree with the expected remaining duration of the task.

We might also wish to ask about expenditures relating to purchases, rentals, contracts and other non-labour costs.

The list of questions is now complete. These are:

· Progress (a percentage)
· Actual Start Date
· Forecast Finish Date
· Actual or Forecast Finish date
· Actual Hours
· Forecast Hours
· Problems

Type 4. Asking about Measure
It is possible that there is no problem at all, even thought the reported percentage trails the expected one. This could be due to the way in which we are measuring progress which might not be linear or proportional to the amount of time passed. For example, marking a up ditch before digging is vital but contributes nothing to the measure of meters dug. Similarly, placing protective gear before starting to paint itself provides no value to the 'score' of square meters painted. Non-linear relationships can also occur through the mechanism of a later speed-up due to the gaining of experience, the amalgamation of multiple sub-tasks within a single one, or through the poor selection of the progress metric.

Here we should check on the nature of what was actually done. The forecast finish date asked of the team will help us to assess whether or not there is a structural problem with the work or whether the problem is simply one of the inadequacy of how we are measuring progress.

Multiple Causes
Of course it is possible for a combination of causes to fully explain any problems we are seeing. We then require a means of analysing this and breaking out the causes into the identifiable components as we did above. This requires some analysis. There are two main methods of attach here. One is the 'Earned Value' analysis and the other, which is equivalent, is the 'Critical Ratio' method. These will be subjects of our attention in future articles.