Reporting progress

A progress report tells the people who fund and steer a project where it stands against the plan, and what they must decide. It goes wrong in two ways: progress was counted badly, or it was known and not said.

1. Why “90% done” lasts so long

The 90% syndrome is a project that reaches about 90% on schedule, then stalls and finishes at about twice the planned duration [1]. Subjective reporting is the second cause. The first is rework nobody has found yet.

Ford and Sterman’s Python project, a chip design rather than software, counted progress in lines of design code. It was 73% complete at its week-39 deadline, its rate halved, and it finished in week 69. Work was marked done, its errors surfaced later in testing, and everything built on it went round again: “the downstream phases outrun the discovery of inherited rework requirements.”

For example, in our software reading, a word-processor team marks export features done when merged. Integration testing in week 30 finds the file layer mishandles three character encodings, and every feature that writes a file goes back. The board said 90%; nothing about the count was subjective.

So “done” has to include tested. Brooks wants milestones “defined with knife-edge sharpness” [2]; McConnell makes them binary, done or not done [3]. Percent complete is calculated, never asked for: finished tasks over all tasks, work under way counting zero [4].

2. Reports fail more from silence than from ignorance

Snow and Keil split status error in two: the project manager may misperceive the true status, or perceive it and report it better [5]. Under moderate good-news bias, their model has a truly Red high-risk project reach the executive as Green about half the time, and halving the perception error barely changes that. Distortion is “likely to be significantly higher in organizations where ‘bad news gets you killed.’” The reader of the reports owns the climate.

Silence is the norm. 85% of Milliken’s interviewees had held back an important issue, most often someone’s competence, mostly for fear of being labelled a troublemaker [6]. In Keil’s experiment, willingness to report fell at each step up the hierarchy, and further where messengers had been punished [7].

A manager can change four things:

Walk around and ask “can you show me?”, which turns a percentage into done or not done.
Act on what you hear, or say why not; people stop telling a manager who does nothing.
Ask for one light per dimension (cost, schedule, function), since one overall colour is easy to round up [5].
Print what the colours mean: Yellow comes with a get-well plan, Red has none and asks for help [4].

3. Example: a status report that answers first

A status report asks its reader to decide, so it takes the Minto pyramid: answer, then reasons, then evidence. The usual template puts the decision needed in its last line. Reordered, the word processor’s report opens:

Schedule Yellow: export slips two weeks unless release 1 drops RTF import. Decision needed by Friday. Cost and function Green.

Schedule, Yellow. 9 of 12 milestones done; integration found an encoding defect, two weeks of rework. Get-well plan: move RTF import to release 2.

Cost, Green. 410 hours spent on work budgeted at 450.

Function, Green. Every release 1 feature but export passes its acceptance tests.

Below the lights, the standard contents become evidence: forecasts, baseline and change requests, indicators such as earned value, issues, risks, and the period’s chronicle last. Nothing is added or cut; only the order changes.

Milestone trend analysis belongs there too. At each report, plot every milestone’s forecast date. A flat line is stable; a climbing line is a milestone slipping in small steps, which is how a project gets a year late, “one day at a time” [2].

4. When to use it, and when not

Use answer-first for any report that asks a sponsor to decide. Do not use it where chronology is the content, such as an incident timeline. And no ordering rescues a climate where Red is unsafe.

How solid is this?

Where it comes from. Ford and Sterman’s cases are chip projects and a simulation; the software readings are ours. Brooks, McConnell and Wysocki assert their rules from practice.
What is contested. Snow and Keil’s figures come from a model built on five experts’ estimates: “about half” is a direction, not a measured rate. Keil’s study is a role-play; Milliken’s, 40 interviews.
What we do not hold. Evidence that answer-first reports or walking around reduce distortion, or that binary milestones prevent the syndrome rather than reveal it sooner. Applying Minto to status reports is our step.

Acknowledgments

This page adapts material from lectures by Eduardo Miranda and David Root [8], [9] on software project management.

References

D. N. Ford and J. D. Sterman,
“Overcoming the 90% Syndrome: Iteration Management in Concurrent Development Projects,” Concurrent Engineering: Research and Applications, vol. 11, no. 3, pp. 177–186, 2003, doi: 10.1177/106329303038031.
F. P. Brooks,
The mythical man-month (anniversary ed.). Addison-Wesley Longman Publishing Co., Inc., 1995.
S. McConnell,
Rapid development: taming wild software schedules. Pearson Education, 1996.
R. K. Wysocki and R. McGary,
Effective Project Management: Traditional, Adaptive, Extreme, 3rd ed. Wiley Publishing, 2003.
A. P. Snow and M. Keil,
“The Challenge of Accurate Software Project Status Reporting: A Two-Stage Model Incorporating Status Errors and Reporting Bias,” IEEE Transactions on Engineering Management, vol. 49, no. 4, pp. 491–504, 2002, doi: 10.1109/TEM.2002.807290.
F. J. Milliken, E. W. Morrison, and P. F. Hewlin,
“An Exploratory Study of Employee Silence: Issues that Employees Don’t Communicate Upward and Why,” Journal of Management Studies, vol. 40, no. 6, pp. 1453–1476, 2003, doi: 10.1111/1467-6486.00387.
M. Keil, H. J. Smith, S. Pawlowski, and L. Jin,
“‘Why Didn’t Somebody Tell Me?’: Climate, Information Asymmetry, and Bad News about Troubled Projects,” ACM SIGMIS Database: the DATABASE for Advances in Information Systems, vol. 35, no. 2, pp. 65–84, 2004, doi: 10.1145/1007965.1007971.
E. Miranda,
“Managing Software Development.” 2014.
D. Root,
Managing Software Development. Carnegie Mellon University / Innopolis University lecture series, 2014.

Disclaimer: AI is used for text summarization, polishing and explaining. Authors have verified all facts and claims. In case of an error, feel free to file an issue.