About that coordination thing ....

---

We're all supposed to coordinate. That's written somewhere in the PM literature and taught in bureaucracy school everywhere. And so I was impressed with this bit of wit(*):

"Successful coordinating mechanisms depend on mutuality. The greatest chance of success derives from mutual benefit tied to sufficiently high priority programs

Lesson learned: you haven't coordinated if the other person hasn't acknowledged AND hasn't offered something in return. The "sound of one hand clapping" and "coordination without acknowledgement" are about equivalent.

... "[beware of the] weak coordinating level of [just] interaction rather than [the stronger leverage] in budgeting and policy"

Be consequential: Well, no one wants the label of "weak coordinator", so let's all go for "strong"; to wit: let's spend our energy and influence being consequential.

"Budgeting and policy" are C-suite speak.
You, on the other hand, may be working execution rather than forming policy.
Nonetheless, even at the execution level, there may be more areas of leverage than 'money and resources' and a hammer on direction (strategy), but those are two pretty good ones.

Thus, if you're not "coordinating" in those areas, what is it you're coordinating about that is consequential?

-----------------
(*)Dr. L. Parker Temple, III
Policy advisor to President Reagan

---

Buy them at any online book retailer!

It's as easy as 1-2-3!

---

Counting, positioning, or measuring: what's in a number?

Remember pre-school or kindergarten: we all "learned our numbers".
Ah! but did we?

Want to count something? Just use the integers, starting at 0 and going in familiar step: 1, 2, 3 ....
The count takes on the dimension of what you are counting: dollars, inches, meters, liters, etc
You can do arithmetic on count, but because of the dimensioning, the results may or may not be viable: square inches are ok, but square dollars are not.

Want to rank or position something? Again, we fall back to the integers -- 1st or 2nd position is good; position 1.2 in a queue has no meaning or implementation. And, there is no dimension per se in a position.
Some arithmetic still applies, but it's tricky. Addition is not commutative:

• You can add 1 to the first position to get the second position, 
• But you can't add first position to a 1. Stuff like that.

Want to measure something? You can use any rational number for measurement. (a number that can be fashioned by the ratio of two numbers). Really, anything on a measurement scale is rational and can be a measurement.

But there are irrational numbers which can not be formed by a ratio (like "pi"). Nonetheless, you can measure with irrational numbers. The area and circumference of a circle are measured with "pi"

For a number to be useful in measuring, every number in between has to be meaningful. That's why you don't do measurements with ranks and positions: the in-between numbers are not meaningful.

Calibration: And, to be meaningful, the scale has to be calibrated.  A ruler with irregular spacings or a warped or bent rule, or guesses without reference to benchmarks or other reference classes are uncalibrated. And, thus, every number in between is not meaningful.

Project management
And so, where does the rubber meet the road in project management?

• Budgets, schedules, resource estimates and utilization need calculation, measurement, and counting
• Anything else that's quantitative

We're done here!

---

Buy them at any online book retailer!

To simplify ... or not?

---

Shim Marom has interesting post on complexity wherein he says this:

"A lack of an intellectual capacity to grasp a complex system is not a sufficient argument or drive for simplification.

If you artificially simplify a complex system you end up with a different system that, while simpler, is fundamentally and conceptually different from the one you started with and thus, simplification ends up with destruction."

So, what are we to do about a system we don't understand? Should we:

• Get a smarter guy to understand it for us? Possibly; we can't all understand the particle collider
• Design in some fail-safe stuff so that even a chaotic outcome is contained? Yes, fail-safe is always a good idea if you have the right assumptions (See: Fukushima, March, 2011)
• Design a different system altogether -- one that we can understand? Yes, that might be a good idea (See: HAL in 2001: A Space Odyssey)
• Do the destructive simplification Marom talks about?

A system engineer would say: "Yes" to all of the above, situationally, as required.

About destruction
I suggest that "destruction" could be the intended end-game insofar as if you can't understand a system you may not be able to control it, and certainly can't predict its behavior. So, "destruction" to a simpler device may be an important and required objective. Lord knows, we have enough stuff we don't really understand!

CAS is not for everyone:(*)
Also, when discussing complexity, especially adaptive complexity, one must be careful not to cross domains: CAS in biological and chemical systems, and others like weather systems, is not a phenomenon we have to deal with in man-designed physical systems that operate within reasonable physical limits. To impute CAS properties improperly is one of the common errors I see.
==========
(*) Complex Adaptive Systems: the behavior of the ensemble is not predicted by the behavior of the components. They are adaptive in that the individual and collective behavior mutate and self-organize

---

Buy them at any online book retailer!

The first thing you do to reduce risk ....

---

The first thing you do to reduce risk .... is: loosen the coupling between sources of effects. Create buffers; remove dependencies; install redundancy.

• This is a concept from System Engineering (buffers, dampers, redundancy; but also loose tolerances; fuses; barriers and walls ... anything that inhibits propagation of effects)
• This is a concept from scheduling (Critical Chain by Goldratt; buffers to critical path)
• This is a concept from the Theory of Constraints (also by Goldratt; manage the coupling constraints between processes)
• This is a concept supported by elementary statistics (shift right bias)
• This is a concept from anti-fragile theory (by Taleb; in effect, shock absorbers)
• This is the concept of the "normal accident" (by Perrow, aka: stuff happens! So, expect that it will)

Coupling applies to the project office
And, this coupling idea applies not only to physical systems but to organizations. (Again, Charles Perrow). Organizations are systems, after all.  One miscue in an organizational element is to be absorbed and isolated from other. In an extreme: quarantine.

---

Buy them at any online book retailer!

Hub and spoke project architecture

---

On the HBR Blog Network, Andrew Shipilov has a eye-catching post on "hub and spoke" project networks, or alliances between project partners, as he describes them.

(Say "network" to me and I always jump first to a mind's-eye image of a "mesh", but actually that's one of several general ways to think of networks, and in most situations not a good general model for governance.)

Shipilov posits that simple hub-and-spoke arrangements in truly complex and challenging systems, with the prime contractor and an SI (system integrator) at the hub, inhibits critical interactions between the other partners, each of which is on a spoke. He attributes some project failures to this governance model.

What to replace it with? After all, hub-and-spoke is the essence of prime contractor command-and-control over the myriad partners, to say nothing of the legal details of who has privity of contract.

Shipilov recommends the "alliance network" wherein there are multi-lateral relationships for innovation, data exchange, and cooperation, not necessarily under the watchful eye of the SI (though, if the SI is on the ball, all the consequential stuff is known at the PMO)

About the alliance network, we are told there are these advantages:

"First, alliance partners are more likely to deliver on their promises.  If information flows freely among interconnected partners, how one firm treats a partner can be easily seen by other partners to whom both firms are connected. So if one firm bilks a partner, other partners will see that and will not collaborate with the bilking firm again.

Second, integrated networks facilitate fine-grained information exchanges because multiple partners have relationships where they share a common knowledge base. This shared expertise allows them to dive deep into solving complex problems related to executing or implementing a project."

Fair enough. But one caution: You can't be a control freak and sleep nights with an alliance network!

---

Buy them at any online book retailer!

Value stream mapping

---

Value stream mapping seems to be a new label on old wine. But nevertheless, the wine ages well. In the old days, we simply called it process mapping.

Value stream mapping derives from the Lean community, where of course the focus is on leaning out non-value add. So, in value stream mapping, each activity, to include the workflow of authorization and other governance, and ancillary activities, like a trouble report or a status report, is evaluated for value-add.

And, of course that begs the question: what is value-add? There is an answer, of course, but it may take a bit of customization to make it work everywhere. Simply put: anything that is ultimately delivered to the customer or makes the customer deliverable a good thing in the customer's eyes.

A lot of governance would not fit this definition directly, but most indirect activities don't. Nevertheless, most practical organizations can't live without them, so there's a certain valuable non-value overhead that goes along with everything.

One thing I do like about value stream mapping is the clarity of the diagramming. Take a look at this diagram:

If you're interested in more, this diagram came from a nice post at LeadingAnswers

---

Buy them at any online book retailer!

Trust and loyalty

---

From time to time, a profound thought strikes here at Musings. Today, it's these questions:

Is it necessary for there to be trust in order that there be loyalty?
Can there be loyalty and simultaneously mistrust?

Spoiler alert: there's no right answer. It's a matter of your values and beliefs, for which there is no proof, validation, or algorithm.

So, where did this come from?

1. In my agile classes, we discuss the desirable (or essential?) elements of leadership in the agile environment. The word trust comes up in almost every student input.
   I don't recall 'loyalty' ever coming up (though I did search the archives), either as a quality looked for in a leader or expected to be given to a leader
   
2. In the Winston Churchill biography "Churchill the Lion", the biographers -- William Manchester and Paul Reid -- describe Churchill's relationship with Josef Stalin -- from 1942 onward when the USSR allied with the U.S. and Britain in WW II -- as mistrustful but loyal. I was really struck by that assessment. (Perhaps this is the earlier version of Reagan's "trust but verify")

So, back to the questions posed above; I think this:

•  I can be loyal to an institution (team, project, business unit, agency) without being trustful of its tactical leadership. However, if the mistrusted leadership is then strategic and becomes the strategy of the institution, then you lose me. (mistrust tactically, but verify strategically)
  
• At a personal level, I can't be distrusting and loyal to a person at the same time. At a personal level, trust and loyal have to go together.
  
• I think, without knowing, that WSC was loyal to the cause represented by the alliance with the USSR without being trusting of its leadership. I get it; it can work -- but only for a short time to overcome a major issue where everyone is needed on some level.

And, Mike Clayton has an excellent piece on 10 qualities of leadership -- but loyalty (given or expected) is not among them. So, another point of reference for those looking.

(Disclosure: I resigned an executive position in a large company when I could no longer trust a more senior executive and felt I could not be loyal to him, so that experience probably colors my thinking)

And, ONE MORE THING: you don't get the word 'respect' on leadership attribute lists. I wonder if trust-respect and loyalty somehow go together... could you possibly trust someone that you don't respect? Perhaps, one begets the other.

---

Buy them at any online book retailer!