The requisite law of variety

---

Now, this could be a bit stuffy: "The Requisite Law of Variety"

But actually, it's an interesting concept to consider, to wit:

• Essential Elements (E): these are outcomes, results, or other artifacts that you want to have some control over, even if you are Agile
• Disturbances (D): these are events or actions that impact E .... usually there are a lot of these!
• Regulation (R) or controls: these are the means or actions to limit the impact of D's. Even in the Agile world, there are some controls or protocols to regulate the pace and rhythm
• Passive capacity (K): in effect, buffers and elasticity that limit the fragility of the system and allow for some absorption of D without breaking E 

The Law is a bit mystical when expressed as math, essentially saying:

"the the variety -- or set -- of the E's that you need control over should be greater than (1) the variety disturbances-reduced*-by-regulation and (2) further disturbances-reduced-by the buffers or elasticity."
* reduced, absorbed, or mitigated

Anthony Hodgson puts it this way:

[The Law of Variety] ... leads to the somewhat counterintuitive observation that the regulator must have a sufficiently large variety of actions in order to ensure a sufficiently small variety of outcomes in the essential variables E.

This principle has important implications for practical situations: since the variety of perturbations a system can potentially be confronted with is unlimited, we should always try maximize its internal variety (or diversity), so as to be optimally prepared for any foreseeable or unforeseeable contingency.

If you are familiar with the ideas of "anti-fragile" in system design, this last sentence is a good alternate phrasing for what makes systems anti-fragile, i.e. resilient

---

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 Agile Canon

---

I thought this posting on the "Agile Canon" was worthy of passing along in its entirety. So, there's the link for a pretty good read on the most important elements of a canon that all should be interested in adopting:

1. Measure Economic Progress: Outcomes, means to measure, means to forecast
2. Proactively Experiment to Improve: Assess options, embrace diversity and variability, execute experiments to improve
3. Limit Work in Process: Visibly track work by category, communication delays are a form of WIP
4. Embrace Collective Responsibility: don't blame others, don't blame others by name, don't blame the circumstances, accept and embrace responsibility for outcomes
5. Solve Systemic Problems: Be de-constructive to the root cause, be aware of both static and dynamic influences

---

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

Math at Christmas time

---

You know, I wrote a book on quantitative methods in project management. But somehow I missed covering these equations!

Best Wishes for the Holidays!

---

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

---

To succeed with agile, management’s need for results must be greater than their need for control. —Israel Gat, formerly of BMC Software

This statement is so profound, I think I'll just let it stand on its own.

Source: Originally quoted by Dean Leffingwell in "Agile Software Requirements", Chapter 22.

---

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

Unity of effort

---

In the Harvard Business Review, there is an interview with Admiral Thad Allen, the retired Coast Guard commandant and the "National Incident Commander" for the Gulf oil spill some years ago.

Entitled "You have to lead from everywhere", it's a good read for those interested in how an experienced manager with a proven track record approaches different situations under different degrees of urgency and stress.

Interviewer Scott Berinato took the title from a reply Allen made to the question: "In a major crises...do you think it's more important to lead from the front or from the back?", to which Allen replied: "You have to lead from everywhere".

Mental models
Here's the point that struck me: Allen says he approaches every assignment with a number of different mental models of how command might be exercised....Allen is an admirer of Peter Senge, noted MIT advocate of mental models....and may change models as events unfold.  In many situations he has faced, he states that the chain of command model simply doesn't exist!

OMG! No chain of command?!

What he's saying is that in some situations there is no single manager is in charge.

OMG! No one in charge?!

But, Allen can work this way and make it effective. He calls for "unity of effort" rather than "unity of command"

Unity of Effort vs Unity of Command
Allen makes a very interesting distinction in those cases where the organizational model simply does not converge....parallel lines rather than a pyramid, or multiple pyramids with a loosely layered level of federation and coordination:

In what I would call a “whole of government response”—to a hurricane, an oil spill, no matter what it is—that chain of command doesn’t exist. You have to aggregate everybody’s capabilities to achieve a single purpose, taking into account the fact that they have distinct authorities and responsibilities. That’s creating unity of effort rather than unity of command, and it’s a much more complex management challenge.

Admiral Thad Allen, USCG [Retired]

Program management lesson
So, what's the program management lesson here? Well, of course, the lesson is right in the word 'program' that implies multiple projects ostensibly working toward a common objective.

And, of course, the objective may change, forced by unforeseen events.

And if some of the effort is in the government, and some is in contractors and NGO's, and even within the government there are state and federal, or USA and ROW, there's a lot to be learned by studying the methods Allen has championed.

---

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

Thinking first

---

“It took a year of thinking before we built any prototypes,”

Serge Montambault,

Mechanical engineer with Hydro Québec’s research institute

And, to top it all off, his project to build robots to inspect high power transmission lines is a business success.

It's remarkable what thinking will do. And of course, take note that from thinking, the next step was prototypes, not full scale development.

Remember the spiral method? It's a prototype-first idea from the last century, inspired by Dr. Barry Boehm of then-TRW. His idea: you can't be sure of which direction to step off when faced with technology feasibility issues, so take the time to experiment to find the right direction.

---

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

More on the risk matrix

---

In 1711 Abraham De Moivre came up with the mathematical definition of risk as:

The Risk of losing any sum is the reverse of Expectation; and the true measure of it is, the product of the Sum adventured multiplied by the Probability of the Loss.

Abraham de Moivre, De Mensura Sortis, 1711 in the Ph. Trans. of the Royal Society

I copied this quote from a well argued posting by Matthew Squair on Critical Uncertainties entitled Working the Risk Matrix.  His subtitle is a little more high brow: "Applying decision theory to the qualitative and subjective estimation of risk"

His thesis is sensible to those that really understand that really understanding risk events is dubious at best:

For new systems we generally do not have statistical data .... and high consequence events are (usually) quite rare leaving us with a paucity of information.

So we end up arguing our .... case using low base rate data, and in the final analysis we usually fall back on some form of subjective (and qualitative) risk assessment.

The risk matrix was developed to guide this type of risk assessments, it’s actually based on decision theory, De’Moivres definition of risk and the principles of the iso-risk contour

Iso-risk contour

Well, I've given you De’Moivres definition of risk in the opening to this posting. What then is an iso-risk contour?

Definitions:
"iso" from the Greek, meaning "equal"
"contour", typically referring to a plotted line (or curve) meaning all points on the line are equal. A common usage is 'contour map' which is a mapping of equal elevation lines.

So, iso-risk contours are lines on a risk mapping where all the risk values are the same.

Fair enough. What's next?

Risk matrix

Enter: decision theorists. These guys provide the methodology for constructing the familiar risk matrix (or grid) that is dimensioned impact by probability. The decision guys recognized that unless you "zone" or compartmentalize or stratify the impacts and probabilities it's very hard to draw any conclusions or obtain guidance for management. Thus, rather than lists or other means, we have the familiar grid.

Each grid value, like High-Low, can be a point on a curve (curve is a generalization of line that has the connotation of straight line), but Low-High is also a point on the same curve. Notice we're sticking with qualitative values for now.

However, we can assign arbitrary numeric scales so long as we define the scale. The absence of definition is the achilles heel of most risk matrix presentations that purport to be quantitative. And, these are scales simply for presentation, so they are relative not absolute.

So for example, we can define High as being 100 times more of an impact than Low without the hazard of an uncalibrated guess as to what the absolute impact is.

If you then plot the risk grid using Log Log scaling, the iso-contours will be straight lines. How convenient! Of course, it's been a while since I've had log log paper in my desk. Thus, the common depiction is linear scales and curved iso-lines.

Using the lines, you can make management decisions to ignore risks on one side of the line and address risks on the other.

Common problems

There are two common problems with risk matrix practices:

1. What do you do with the so-called "bury the needle" low probability events (I didn't use 'black swan' here) that don' fit on a reasonably sized matix (who needs 10K to 1 odds on their matix?)
2. How do you calibrate the thing if you wanted to?

 For "1", where either the standard that governs the risk grid or common sense places an upper bound on the grid, the extreme outliers are best handled on a separate lists dedicated to cautious 360 situational awareness

For "2", pick a grid point, perhaps a Medium-Medium point, that is amenable to benchmarking. A credible benchmark will then "anchor" the grid. Being cautious of "anchor bias" (See: Kahneman and Tversky), one then places other risk events in context with the anchor.

If you've read this far, it's time to go.

---

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

Storyboards ... if you can't draw it...

---

A great technique for writing proposals, papers, or books -- as I do a lot -- is to storyboard the ideas.

My favorite expression: "If you can't draw it, you can't write it!"

Here's Einstein on the same idea:

I rarely think in words at all. A thought comes and I may try to express it in words afterwards

If you're not a storyboard person, check out this website for insight...

---

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

Data quality, data parentage

---

My early career was in technical intelligence, so I was struck by this phrase applicable not only to that domain, but to my present domain -- project management:

"The value of [information] depends on it's breeding. .. Until you understand the pedigree of the information you can not evaluate a report. We are not democratic. We close the door on intelligence without parentage."

John LeCarre

Some years ago, Chapter 11 of the PMBOK was rewritten to include "data quality" as an element of risk understanding and analysis. Certainly, some of the motivation for that rewrite was the idea of information parentage -- information qualities.

The idea here is not that data has meet a certain quality standard -- though perhaps in your project it should -- but that you as project manager have an obligation to ascertain the data qualities. In other words, accepting data in a fog is bound to be troublesome.

If some attributes are unknown, or unknowable, at least you should do the investigation to understand whether or not the door should be closed. After all: there's no obligation to be democratic about data. Autocrats accepted!

---

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

Kahn Academy on game theory

---

Chapter 12 of my book, "Maximizing Project Value", posits game theory as tool useful to project managers who are faced with trying to outwit or predict other parties vying for the same opportunity.

When John von Neumann first conceived game theory, he was out to solve zero-sum games in warfare: I win; you lose. But one of his students challenged him to "solve" a game which is not zero-sum. To wit: there can be a sub-optimum outcome that is more likely than an outright win or loss.

For this most part, this search for compromise or search for some outcome that is not a complete loss is throughout the business world, the public sector (except, perhaps, elective politics), and certainly is the situation in most project offices.

The classic explanation for game theory is the "prisoner's dilemma" in which two prisoners, both arrested for suspected participation in alleged crimes, are pitted against each other for confessions.

The decision space is set up with each "player" unable to communicate with the other. Thus, each player has his/her own self interest in mind, but also has some estimate of how the other player will react. The decision space then becomes something like this:

1. If only you confess, you'll get a very light sentence for cooperating
2. If you don't confess but the other guy does, and you're found guilty, you'll get a harsher sentence
3. If both of you confess, then the sentence will be more harsh than if only you cooperated, but less harsh than if you didn't cooperate
4. If neither of you confess, risking in effect the trust that the other guy will not sell you out, you and the other prisoner might both go with a fourth option: confess to a different but lesser crime with a certain light sentence.

From there, we learn about the Nash Equilibrium which posits that in such adversarial situations, the two parties often reach a stable but sub-optimum outcome.

In our situation with the prisoners, option 4 is optimum -- a guaranteed light sentence for both -- but it's not stable. As soon as you get wind of the other guy going for option 4, you can jump to option 1 and get the advantage of even a lighter sentence.

Option 3 is actually stable -- meaning there's no advantage to go to any other option -- but it's less optimum than the unstable option 4.

Now, you can port this to project management:

• The prisoners are actually two project teams
• The police are the customer
• The crimes are different strategies that can be offered to the customer
• The sentences are rewards (or penalties) from the customer

And so the lesson is that the customer will often wind up with a sub-optimum strategy because either a penalty or reward will attract one or the other project teams away from the optimum place to be. Bummer!

There are numerous YouTube videos on this, and books, and papers, etc. But an entertaining and version is at the Khan Academy, with Sal Khan doing his usual thing with a blackboard and and voice over.

And, you can read Chapter 12 of my book: "Maximizing Project Value" (the green/white cover below)

---

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 in the critical systems space

---

I read a recent posting about agile from a very odd corner of the PM space for an agile conversation to be: CriticalUncertainties, a (conservative) blog about critical safety and failure (or fail safe) requirements in complex systems.

But, nonetheless, we get this input from critical systems safety expert Mathew Squair:

When you don’t know what to do, don’t sit down and plan what you don’t know, get people moving, talking, collaborating and making stuff. Then out of that activity you’ll find the information will emerge that will allow you to make decisions......

As Tom Peters points out we need to understand whether our methodologies have an inherent bias for action or a bias for planning, and then whether the situation is complex (but understood and stable) where planning will pay off or uncertain (with high novelty and volatility) where talking, thinking and looking at the small grain issues to build a picture of where we are is what we ought to be doing.

---

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

Understanding project statistics

---

Chapter 14 from the GAO Cost Estimating Manual on "Cost Risk and Uncertainty" is a good read, easily understood, and very practical in its examples.

Here's one illustration that I particularly like.  When you look at it, it's understood in a moment that the repeated random throw of two dice generates a probability density function [PDF] that has a bell-shape curve.

Statisticians call this phenomenon the Central Limit Theorem: random occurrences over a large population tend to wash out the asymmetry and uniformness of individual events, such that a "central tendency" occurs around the more probable outcomes.  A more 'natural' distribution ensues.  The name for this somewhat natural distribution is the Normal distribution, more commonly: the bell curve.

Here's what it looks like to a project manager.  
Regardless of the distribution risks in either cost or schedule as adopted by work package managers for each individual work package, in the bigger picture at the summation will tend to be a bell-shaped distribution of risk.

Consequently,  the project manager's doesn't really need to understand the parameters of variation for each work package. The Central Limit Theorem does all the work. Triangles, Rayleighs, and even Binominal distributions are become bell shaped in the big picture.

  This diagram is (again) from Chapter 14 of GAO's manual:

If the risk analyst generates these data from a simulation, like a Monte Carlo simulation, then the numeric statistics like variance and standard deviation are usually reported, along with the cumulative probability more commonly called the "S" curve.  In the diagram, on the right side, we see the cumulative curve plotted and labeled on the vertical axis as the confidence level.  With a little inspection, you will realize that the cumulative curve is just the summation of the probabilities of the bell curve that is adjacent on the left.

The GAO manual, and especially Chapter 14, has a lot more information that is well explained.  Give it a read.

---

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

Adding staff -- slowly

---

First, we have "Brooks Law", as given in the classic case study "The Mystical Manmonth" by Dr. Fred Brooks:

"Adding staff to a late project makes it later"

I was no more thinking about that idea, than I read this missive in a history of the Civil War that I am engaged with:

“The veterans looked across the open ground at the newcomers with complete and unconcealed skepticism and hostility. In every line of their bearing—in the set of their jaws, the tilt of their heads, the look about their eyes peering out from under those valued hatbrims—they expressed for all to see the age-old, impersonal, unformulated feeling of the veteran for the recruit:

We have had it and you have not, and until you have been where we have been and have done what we have done we do not admit you to any kind of fellowship.”

Excerpt From: Catton, Bruce. “Glory Road.” This material may be protected by copyright.

OK, that might be tougher than the normal project team might be, but in my experience, until there is bonding over a common stress, there's not cohesion, and maybe not even functional integration.

So, as in war and most other things, to speed assimilation along, sometimes a bonding experience is needed. Thus, all the bonding games, etc, but it often works. Else, just put everybody in the deep end. Survival will do all that is necessary

And, did I mention virtual teams: there's really not a difference, not really.

---

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

5 levels of Agile planning ... and the DoD

---

Some years ago I picked up this nice summary image of agile planning over several time cycles. It came from a white paper at AgileConnection.com " entitled "Scaling Agile Processes: Five Levels of Planning

Fortunately, to give some credibility to his thesis, the author says right up front that agile methods don't scale to enterprise level without some changes!  He is so right. Since 2014 when the paper was written, SAFe (Scaled Agile Framework) and other scaling methodologies have come along and acquired creds in the community

So, as agile has matured, acquired some common sense, and worked its way into mainstream project protocols,  even large scale organizations, like DoD, have embraced some tenants of agile methods.

You can check out some of the references to DoD practises I've gathered from Glen Alleman and others. As well, read some background in the white paper I wrote "back in the beginning" about agile in the DoD.

• Handbook for Implementing Agile in Department of Defense Information Technology Acquisition
• Defense Agile Acquisition Guide
•  Considerations for Use Agile DOD Acquisition
• Agile Methods: Selected DoD Management and Acquisition Concerns
• Thinking about Agile in the DOD  
• DOD Agile Adoption

 Or, you can take a look at one of DoD's software journals, "Crosstalk" and search the journal for 'agile'

Better yet, give a read to "Project Management the Agile Way: Making it work in the enterprise, 2nd Edition"

---

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

Terminator conundrum

---

There's some buzz about the DARPA program to develop autonomous sensors and weapons (potentially) that are AI driven but rely on relatively inexpensive platforms.

Here's what Robert O. Work, Deputy Defense Secretary is quoted as having said:

You could “use the tactical ingenuity of the computer to improve the strategic ingenuity of the human,”

Authors Matthew Rosenberg and John Markoff write that ... "Work believes a lesson learned in [AI applied to ] chess can be applied to the battlefield, and he envisions a military supercharged by artificial intelligence. Brilliant computers would transform ordinary commanders into master tacticians."

Hmmm, does that mean that brilliant computers (a.k.a AI) can turn ordinary PM's into masterful tacticians, following along with their business' strategy?
It's a concept!

---

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 verification game, or gaming verification

---

At Critical Uncertainties I read a post that I hope is meant in the best of humor, but actually it might be quite serious

Here's the setup:

• Customer states requirement
• Customer states requirement verification protocol
• Project team implements protocol
• But wait ... protocol is only statistically applicable

And here's what Critical Uncertainties writes:

".... one realises [SIC] that requirements are 'operationally' defined by their associated method of verification. ..... Now if you're in luck ..... you propose adopting a statistical proof (because it's such a tough requirement and/or there's variability in the process, weasel weasel) of compliance based on the median of a sample of tests.
Using the median is important as it's more resistant to outlier values, which is what we want to obfuscate (obviously).
As the method of verification defines the requirement all of a sudden you've taken the customer's deterministic requirement and turned it into a weaker probabilistic one."

This last thing is the key and merits repeating:

"As the method of verification defines the requirement all of a sudden you've taken the customer's deterministic requirement and turned it into a weaker probabilistic one."

OMG! Did you pull one off on the customer, or did you simply introduce the customer to the realism of the verification protocol?

---

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

You say, but I say ...

---

You say: Value!
I say: Cost

You say: Balanced scorecard -- customer, organization, product, finance
I say: Cost, schedule, scope, quality

You say: Vision -- the long view
I say: Requirements

You say: strategy and strategic alignment
I say: tactics to overcome problems

I also say: I could go on with this but you get the point (I hope).

• "You" are the sponsor, and your context and objectives and measurements are different from "I". 
• I am the PMO; I respond to my measurements, incentives, and context.

We all notice: there is a gap. Sort of a Mars v. Venus thing. And, who is to manage the gap, a.k.a. the risk, between us? Well, that's why they pay PMO the big bucks! To manage all the risks, whether under their control and influence or not.

Project balance sheet
My icon for this is the "project balance sheet"

• "You" are on the left
• "I" am on the right
• And, I have the risk (gap) on my side

"You" have a top-down more-or-less "fact free" vision of things. "I" do things stick by stick, bottoms up, dealing with the facts and estimates. "You" and "I" never actually agree. But we get the gap close enough to move ahead. And, that's the way it is on Mars and Venus

---

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

NIST standards and peanut butter

---

I'm a fan of peanut butter. I have a jar in my hurricane supplies here in Florida.

Nonetheless, I was surprised open a recent NIST blog (*) to find out about "standard peanut butter".

Who knew? I guess there are standards for everything. (I wonder if this one is a good use of tax dollars, however)

From the blog, I learned:

" ..... packaged foods come with a list of nutritional values mandated by the Nutrition Labeling and Education Act of 1990, which is enforced by the Food and Drug Administration.

You may be less aware of where those numbers come from. Well, manufacturers don’t just make them up. They have to do tests. NIST develops food and beverage-related standard reference materials (SRMs) to help them know that those tests are giving them the right answers.

NIST chemist Carolyn Burdette with SRM 2387, Peanut Butter. Credit: B. Place/NIST

When a company buys an SRM from NIST, they are really buying all of the measurements and scientific expertise that went into determining its chemical or physical properties, as well as NIST’s level of certainty regarding those measurements.

(*) National Institute of Science and Technology

---

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

Delivering criticism

---

It was famously said, in a paraphrase: lead people, manage things. I buy into this advice, so I'm always on the alert for something that plays into it.

In a recent posting, I read some advice on delivering constructive criticism that seem pretty sensible, given my own experience of being on both the receiving end and the delivering side of such encounters. And, full disclosure: the first time I really had to do this, I really screwed it up!

So, the main points are:

• Deliver the news in person, not on the phone, Facebook, or by tweet or email!. I once had a boss (vice president) who was fired by email... so chicken-crap by the guy who sent the email.
• Focus on actionable things to do. Seems eminently sensible to be concrete, but often you get this: A friend was told he did not have the "leadership presence" for executive office. What do you do with that?
• Bring praise. I always try to start with praise. In fact, my advice is never come without praise. No one is a complete dolt. Seems kind of backwards to me to start negative and then wind saying: "but you do a lot of stuff well".
• Encourage problem solving, since folks who can see a problem and get it solved always have a job; and those that can't are 'takers' for the most part and always at risk for their job.
• Provide a model. If you're asking for change, there should be a model for guidance. Afterall, if there's no direction to change to, how is one to know where the utility lies?

---

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