Progress only measured in time and cost

• Suspicious progress statuses

• Progress reported as time spent vs planned

• Progress reports as cost spent vs planned

• Earned Value Management report based only on hours

If the task is to bring in hay bales from the field, you would never report the progress as “We have worked for 4 hours out of the planned 8 hours, so we are halfway”. That is because the size of the task is well-defined, the progress is very obvious, and it is a simple project.  BUT you could!

Now think of a complex software project. The joke goes, that they are 80% done 80% of the time. There is no obvious size measure other than the estimated effort (well, there is, but rarely used!), and in the shade of a schedule under pressure, progress is reported using all available optimism biases. Then, also consider the quality of the effort estimate, which is most likely all already overly optimistic and does not include the parts that you could not predict. Then you have the simplified structure behind the 80/80 rule. 

The key is a realistic progress measure. This is simple in a simple project and complex in a complex project, but you do need it.

In software, 5 different ISO standards of Function Points have been available for decades. There are no reason not to use one of them, other than it may reveal an embarrassing organizational poor performance. The use of function points as a size measure has proven to provide many benefits in many places.

Nasa has introduced a “Technology Readiness Level” with a scale from 1, where the basic principles are observed, to 9, where it is validated in Space. Your engineers will easily be able to define something similar that is relevant to your context and will bring progress measures to a new level.

The agile concept of “Definition of Done” creates a rule for completion. The teams decide what it takes to declare a task done, and until then, it is undone. With small tasks(hours), this is good enough because the granularity compensates for detailed task progress measures.

Burn-down charts are also useful when the tasks are small enough.

Always require a realistic progress measure, and for the estimator assessment of the reliability of the estimate.

Time and cost spend is not a proxy for progress. Still important, of course, but only as a reactive measure.

Earned value, based on the true delivered value.

Objective size-measure of the deliverables, and progress reported against these.

A definition of the deliverable’s maturity.