ZaneMeyers/zmVault
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

vault backup: 2026-04-12 02:38:27

Browse Source
This commit is contained in:
Zane Meyers
2026-04-12 02:38:27 -04:00
parent 22e3f13174
commit f961095c89
24 changed files with 474 additions and 66 deletions
Download Patch File Download Diff File Expand all files Collapse all files
how-to-measure-anything-in-project-management.md
+105 -3
View File
@@ -11,10 +11,112 @@ dg-publish: true
---
# _How to Measure Anything in Project Management_
## Review
I think it is fair to say
that _HtMAiPM_ is mostly unoriginal,
being in large part a rehash
of ideas presented in [[hubbard_2020_failure]]
and earlier in _How to Measure Anything_.[^1]
[^1]: I have not read _HtMA_,
Hubbard et al frequently state explicitly that a topic introduced in _HtMAiPM_
was covered previously.
This is not a criticism,
the benefit of _HtMAiPM_ is its accessibility.
Where _TFoRM_ and _HtMA_ use appropriately ambiguous terminology
and examples from varied fields that would benefit from their recommendations,
_HtMAiPM_ is explicitly for project managers,
and uses examples
Many of my criticisms of _TFoRM_
(most presented in [[the-failure-of-risk-management]])
still apply.
## Praise
### Accessibility and Recommendability
It is possible to get the same takeaways from _HtMAiPM_
as from the earlier _TFoRM_,
but to translate risk management terminology to project management
requires continuous mental effort
and an intuition developed without help from Hubbard.
As much as I appreciate when researchers present findings
with specialty-neutral language
so as to not imply their use should be limited to any one field,
I acknowledge that my patience in that regard is uncommon.
It is much easier to recommend _HtMAiPM_ to my peers.
I should think they would be more likely to take me up on it too,
but it is difficult to say due to the [zero product property](https://en.wikipedia.org/wiki/Zero-product_property).
## Criticism
### Conflict of Interest
If I have any hesitation about recommending Hubbard's books
its that sections frequently read like advertisements.
It is worse in _HtMAiPM_ than _TFoRM_
because ~~coauthor~~, one of the coauthors,
~~has some stake~~ in Oxford ~~something~~,
a paid (for profit?) repository of project data
intended for use in reference class forecasting,
a method frequently lauded by the text.
I appreciate that it's usually impossible
for these authors to give impartial recommendations
considering we're talking about innovators
(they can hardly recommend the services
of competitors that don't exist yet),
but they could have done more
to get ahead of the apparent bias.
### Estimator Calibration
As Hubbard explains in _TFoRM_ and _HtMAiPM_ reaffirms,
when Hubbard first began offering calibration training
there were no comparable services available.
In this history both books establish and credit Hubbard
as the pioneer of calibration in business risk management.
Seemingly in contradiction,
_HtMAiPM_ implies in examples of project losses
not just that organizations would have avoided loss
by implementing calibration training programs,
but that they were _negligent_ in their failure to do so.
Regardless of whether calibration training for risk management
is interpreted as [[daniel-kahneman]]'s invention or Hubbard's,
the technique is new enough that its use ought to be the rarity,
not its absence.
***
Also frustrating,
in a book all about the necessity of objective measurement,
the term "calibrated" is not explicitly defined.
Worse, interpretation from context gives
"100% accurate plus or minus a little".
***
In evidence of [[#Conflict of Interest]]
one _would_ expect that a man selling calibration training
would write in this way:
Creating FOMO for his services
and allowing him to interpret individual calibration as favors him.
## Scratch
### ???
> [!quote] [[How to Measure Anything in Project Management - Douglas W. Hubbard & Alexander Budzier & Andreas Bang Leed.pdf#page=112&selection=40,0,41,60|Chapter 4, "Exploration vs. Exploitation"]]
> The analogy of this to project planning is that we can keep trying to design better solutions to a problem before we commit to it.
## Project Options
### Project Options
> [!quote] [[How to Measure Anything in Project Management - Douglas W. Hubbard & Alexander Budzier & Andreas Bang Leed.pdf#page=117|Chapter 4, "Choosing How to Run the Project"]]
> When a project is proposed for budget approval, planners must include a list of additions and reductions... If the project runs out of budget, then deliverables will be removed from the scope.
@@ -22,13 +124,13 @@ dg-publish: true
This is different from alternates,
which are only considered at the time of award.
## Value of Information
### Value of Information
[[How to Measure Anything in Project Management - Douglas W. Hubbard & Alexander Budzier & Andreas Bang Leed.pdf#page=118|Chapter 4, "How Models Indicate What to Measure"]]
[Expected value of sample information](https://en.wikipedia.org/wiki/Expected_value_of_sample_information)
## Estimating Impact under Uncertainty
### Estimating Impact Under Uncertainty
> [!quote] [[How to Measure Anything in Project Management - Douglas W. Hubbard & Alexander Budzier & Andreas Bang Leed.pdf#page=170&selection=40,20,46,58|Chapter 5, "Simple Tools for Measuring Uncertainty and Risk"]]
> There is such a rule, and it is called the "record-breaking probability." It is simply $1/(1+n)$ where $n$ is the number of observations resulting in the various outcomes.