I recently read an article on Heisenberg developers. In a nutshell, the author is arguing that the act of measuring progress has the effect of slowing progress.

Does this principle have an official name (or even a buzzword) in project management circles?

Is this an area of project management research? Is there any evidence that it is true, and in what circumstances?

  • I believe the author would argue that this principle applies when tasks require creativity and exploratory activities; perhaps it does not apply when tasks are neither (see also Task-oriented and relationship-oriented leadership.
    – John Wu
    Commented Sep 22, 2016 at 18:05
  • To be clear, the post you're referring to is a rant, and not a particularly cogent one. From a PM perspective, the process failure was in treating estimates as delivery guarantees and refusing to inspect-and-adapt the process rather than individual work increments. There was nothing inherently wrong in the tool or the (implied) choice of Scrum as a framework.
    – Todd A. Jacobs
    Commented Sep 22, 2016 at 18:08
  • I agree it is a rant, and I don't disagree with your comment. My question is-- on what basis do you make your comment? Is there a principle, body of knowledge, or area of research that strives to examine and prove/disprove your position?
    – John Wu
    Commented Sep 22, 2016 at 18:15

2 Answers 2


This is kind of a trick question. I agree with @CodeGnome that PM controls is a non zero task. It requires the project to stop or slow down turning wrenches in order to participate in the control process. As such, tempo slows so overall time should increase.

However, "slow progress" implies an unfavorable variance from plan when in fact reporting activities for those controls should be part of the plan such that your planning values include that effort. Therefore, assuming a perfectly working process, your progress does not "slow" because it was built in the plan.

This also has a pay now or pay later kind of dynamic. Measuring progress might be a non zero activity; however, good controls mean early visibility on variances, which means early mitigation / course correction, which means better time results.

Now to get more real, there are thousands of random variables at play on a complex project. I would challenge anyone to credibly point at "controls" as a primary or leading driver to an unfavorable time variance. A lot of our results are simply random.

  • +1. David, I agree with you: there's a distinction between capacity and throughput, and controls can certainly improve the overall process. I especially like "pay now or pay later." However, I'd certainly argue that excessive or incorrect controls can hamper project delivery.
    – Todd A. Jacobs
    Commented Sep 23, 2016 at 2:58

Excessive Inspection: A Form of Micromanagement

[Is it true that] the act of measuring progress has the effect of slowing progress[?]

This is true prima facie. Any process, or process control, consumes non-zero time, so the notion that gathering or analyzing metrics to inspect-and-adapt your project takes measurable time shouldn't really be a surprise. The time consumed will vary widely based on the specific controls applied and (again unsurprisingly) by how automated the controls are.

A healthy level of inspection and adaptation are desirable, but if your inspection or feedback process is too frequent or too finely grained then you certainly run the risk of diverting team capacity to reporting instead of towards effective product delivery.

Broadly speaking, excessive inspection is considered a form of micromanagement, and there is a presumption that it has deleterious effects. If you're looking for academic citations about the quantitative effects of micromanagement, I won't be able to help you scan the available literature. However, the qualitative impact of this type of management is widely discussed in agile literature, and is often contrasted with self-organizing principles and results-based management.

  • I do not think this is true prima facie. It is true that asking an individual for a status update will slow them down as an individual, but it is not necessarily true that getting status updates from all individuals in a team will slow the team's overall progress, since the metrics could be used to improve coordination, predict dependencies, and "grease the skids" so to speak. Otherwise why would we have PMs? Thank you for your answer.
    – John Wu
    Commented Sep 22, 2016 at 18:09
  • @JohnWu You're positing that you can consume non-zero time from members of a team without subtracting from the team's total capacity. That's demonstrably false, and one of the many reasons that the 100% utilization fallacy is so detrimental to modern project management. You're also conflating speed of delivery in the small with sustainable delivery. Look for related answers on PMSE about task switching, process overhead, and calculating team capacity to see why this is true, but why it's often worth the trade-offs.
    – Todd A. Jacobs
    Commented Sep 22, 2016 at 18:20
  • I respectfully suggest you have it backwards. Because the 100% utilization fallacy is true, you can in fact consume non-zero time from individuals without subtracting from the team's total capacity. That is the whole point of the fallacy-- you can get greater output with lower utilization, under certain circumstances.
    – John Wu
    Commented Sep 22, 2016 at 18:26
  • @JohnWu You are conflating capacity with throughput. This is a common misunderstanding. Comments are not for extended discussion, so if you have further questions about this distinction, please open another question.
    – Todd A. Jacobs
    Commented Oct 15, 2016 at 8:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.