Actually, you can't measure it

---

We're told repeatedly: you can't manage what you can't measure. Or, you can measure anything -- everything

Actually, you can't

Measurements do the changing
There are may project domains where measurements change the thing being measured, so that the results are incorrect, sometimes dramatically so:

• Many chemical reactions or chemistry attributes
• Some biological effects
• Most quantum effects
• Most very-high or ultra-high frequency systems (VHF and UHF, to extend to micro and millimeter wave systems)
• Some optical effects

 And, of course, many human behaviors and biases are themselves biased by measurement processes

Intangibles et al
Not be left out: the affects and effects of intangibles, like leadership, empathy, the art of communication, and others. Not directly measureable, their impact is a matter of inference. Typically: imagine the situation without these influences; imagine the situation with them. The difference is as close to a measurement -- if you can call it that -- that you'll get.
 

Which all leaves the project where?

• Inference and deduction based on observable outcomes which are downstream or isolated or buffered from the instigating effects 
• Statistical predictions that may not be inference or deduction
• Bayes reasoning, which is all about dependent or conditioned outcomes
• Simulations and emulations

Bottom line: don't buy into the mantra of "measure everything". Measuring may well be more detrimental than no measurements at all

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The value of strategy

---

"I will not take by sacrifice that which I can achieve by strategy"

General Douglas MacArthur

And, so what we have in that philosophy, when put in project context, is the oft-criticized 'brute force approach' vs a more subtle tactical alternative. Where this shows up more often than not is using the right tool for the right job, and preparing the context for using the tools.

We see it all the time: rather than taking the time to obtain -- and perhaps train on -- the right tool, practitioners barge ahead with brute force because they think they are saving time. No strategy required. I have a hammer, so every problem is a nail!

Ooops! It takes more time to clean up the mess than do it right the first time --- and, how many times have you heard that one?

More brute; more force

Remember this from a prior post? "Measure with a micrometer; mark it with chalk; cut it with an axe"? Just brute piling on top of brute

And, of course, the other brute force idea is more force -- more people. More is better -- until you get to Brooks Law: "Adding people to a late project makes it later" *

* Fred Brooks: "The Mythical Manmonth"
More subtle tactics

• First we have the Tom Sawyer approach: get someone else to paint the fence; and, better still, make them think it's a privilege.
• Ignore the inconvenient: Also known as: answer the question you wished they had asked and not the question asked. And, jump over, around, or dodge adversity -- the MacArthur approach
• Don't confuse cost and unit cost: experts may cost more per hour, but throughput is what counts. They may finish a lot faster and better. This is the case for "made in America"

---

Historians are in general accord that during the Pacific war MacArthur was able use strategy both as a force multiplier and a means to avoid casualties more effectively than any other strategic leader. *
At the single battle of Anzio in Italy, 72K casualties; in 2 years in the campaigns from Australia to the Philippine invasion, MacArthur suffered 27K casualties. There are many other examples.
* From: "American Caesar" by William Manchester

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Timing is not everything

---

"Just because something happens after something else happens doesn't mean it happens because something else happened

• Show me your data
• Show me your assumptions
• Tell me what questions you asked
• Tell me why you didn't ask other questions"

From the TED Radio Hour, "Big Data"

So, what we have here is the tyranny of the "Three Cs" *

• Coincidence, perhaps better written as co-incident to emphasize the timing of multiple incidents, but having no other coefficients or linkages among them
• Correlation, meaning one effect or outcome is predictable upon the occurrence of another, though the "other" outcome may have many contributors, so the correlated effects may be "weak"
• Cause-and-effect, meaning one effect or outcome is both predictable by- and, indeed, caused by the presence -- or not-presence -- of another

It seems we always are confronting the confusing rule that "correlation is not causation, but causation requires correlation"

Chapter 2 of my book "Quantitative Methods in Project Management" goes into these ideas in more depth (did I mention it's available at any online book seller?)

Of course, when there is a human in the loop, then all of the correlating or causative linkages are influenced by biases, most non-linear and very situational, but some amenable to "game theory" which is discussed in other posts in this blog

---

* There is a 4th C: co-variance, an ideas from statistics. Related to correlation, co-variance describes how the spread -- or distribution -- of uncertain or random outcomes of one thing is made different in some sense by the presence of another random or uncertain outcome.
If there is zero co-variance, then the uncertainties are "independent" of each other; otherwise they are not.
In most project environments we can't actually measure co-variance; what we can do is test for independence and thus infer a co-variant effect, or not.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Value and values

---

Value and values are only one letter apart

Anonymous

If you're interested in a soap opera depiction of the early PC wars, you might tune into AMC's "Halt and Catch Fire" 2-season drama. The first season is on Netflix if you've missed it.

On display is certainly the conflict between value and values

• The former being the "end"
• The latter being the "means"

And, the conflict being whether the sometimes duplicitous values put the value out of reach, or so taint the value as to make it unworthy, or really whether the value is worth the values endured.

You can be your own judge

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The 15 commandments of safety-critical software

---

The following is borrowed unashamedly from Matthew Squair at Critical Uncertainties:

"Herewith, are the 15 commandments for thine safety critical software as spoken by the machine god unto his prophet Hermann Kopetz.

1. Thou shalt regard the system safety case as thy tabernacle of safety and derive thine critical software failure modes and requirements from it.
2. Thou shalt adopt a fundamentally safe architecture and define thy fault tolerance hypothesis as part of this. Even unto the definition of fault containment regions, their modes of failure and likelihood.
3. Thine fault tolerance shall include start-up operating and shutdown states
4. Thine system shall be partitioned to ‘divide and conquer’ the design. Yea such partitioning shall include the precise specification of component interfaces by time and value such that  all manner of men shall comprehend them
5. Thine project team shall develop a consistent model of time and state for even unto the concept of states and fault recovery by voting is the definition of time important.
6. Yea even though thou hast selected a safety architecture pleasing to the lord, yet it is but a house built upon the sand, if no ‘programming in the small’ error detection and fault recovery is provided.
7. Thou shall ensure that errors are contained and do not propagate through the system for a error idly propagated  to a service interface is displeasing to the lord god of safety and invalidates your righteous claims of independence.
8. Thou shall ensure independent channels and components do not have common mode failures for it is said that homogenous redundant channels protect only from random hardware failures  neither from the common external cause such as EMI or power loss, nor from the common software design fault.
9. Thine voting software shall follow the self-confidence principle for it is said that if the self-confidence principle is observed then a correct FCR will always make the correct decision under the assumption of a single faulty FCR, and only a faulty FCR will make false decisions.
10. Thou shall hide and separate thy fault-tolerance mechanisms so that they do not introduce fear, doubt and further design errors unto the developers of the application code.
11. Thou shall design your system for diagnosis for it is said that even a righteously designed fault tolerant system my hide such faults from view whereas thy systems maintainers must replace the affected LRU.
12. Thine interfaces shall be helpful and forgive the operator his errors neither shall thine system dump the problem in the operators lap without prior warning of impending doom.
13. Thine software shall record every single anomaly for your lord god requires that every anomaly observed during operation must be investigated until a root cause is defined
14. Though shall mitigate further hazards introduced by your design decisions for better it is that you not program in C++ yet still is it righteous to prevent the dangling of thine pointers and memory leaks
15. Though shall develop a consistent fault recovery strategy such that even in the face of violations of your fault hypothesis thine system shall restart and never give up."

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Construction PMO

---

I don't write about construction projects all that often, but lately that's been my thing: construction... roofing, HVAC, electrical, even some plumbing and floors, etc

The PMO construction extension to the PMBOK is pretty much a non-starter in my opinion.

The place to start is the AIA -- aia.org -- the American Institute of Architects. And, it's not just for architects: general contractors, contract managers, and PM's all find really good stuff.

And,you don't have to be an AIA member to take advantage of a lot of the stuff, including sample contract documents, of which they have dozens, if not several dozens. However, be watchful of the copyright claims

Here's the thing. There are these two important points to grasp:

1. There are generally four players in construction: the architect (or engineer), general contractor, attorney, and owner (or buyer). Read any AIA contract template and you'll find "the architect shall...; the GC shall..., etc)
2. Often, the owner and the general contractor (GC) both will have project managers, though sometimes the architect or the GC plays the role of PM for the owner. So, which one are you?

With four major players, you'd think the communication channels would be about 15 (using the N-squared minus 1 rule, where N is the number of communicators).

But no! My observation and experience is that communications in a construction environment is not a mesh; the communications architecture is hub-and-spoke.

And, guess who is at the hub; guess who is the risk manager managing all the sequences and buffers among players? Right! You are, if you are the PMO for the owners (or possibly the GC if the owner is contracting "turn key" with the GC)

• It's almost childish the way the various independents and independent contractors insist on communicating through the hub. If a conference is needed, only the PM can call for it, it seems.
• And, since most of the construction industry multiplexes the white space among many jobs, to maintain any kind of project schedule requires constant attention to sequences of who works when
• And, did I mention the supply chain? Everyone seems to work "just in time", maintaining minimum inventory, and thereby pushing buffers and sequencing to the limit! 

Conclusion: the number one skill of a construction PMO is communication ... far and wide, and often!

• Tell them what you are going to tell them
• Tell them
• Tell them what you told them!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Agile and the sailing analogy

---

In one presentation to a PMI chapter on Agile project management I used a sailing race analogy. I've used this analogy before, but this time there was some 'Q&A' that was worth passing along.

The first thing is that audience was shocked (shocked!) to learn that agile projects have plans, and even more shocking that earned value concepts (that is: earning some value for the investment made) is also alive and well.

The second thing is that those from large companies lamented (I won't say complained because they didn't) that executive managers had little idea about the change in management paradigm that is the most pervasive aspect of agile. It's not the technical practices: those are largely like those in other software methodologies. But it's the change in management practices and thought that is different.

What's different?

• What's different is that best value is preferred over a fixed scope specification;
• what's different is that matrix management at the team level, sprint to sprint, must be put aside;
• what's different is that the team, in collaboration with someone holding the customer/users proxy has to be trusted to apply the available investment is the best possible way; and
• What's different is that the project manager manages to milestones that have user/customer/stakeholder value and not to the details of a networked CPM schedule.

Take a look and see if you don't agree

Agile for project managers - A presentation for PMI from John Goodpasture

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog