Project Bulls**t

---

Many fine books have been written about 'bull' and its excrement, 'bulls**t' (*). Indeed, such may go back to at least the 17th century, if not before, as written into plays and documents of the era.

And so, is it any surprise that, four centuries on, many in the PM profession pride themselves as good bulls**t detectors, having the cultural training to recognize such that comes from a lifetime of exposure and experience?

Indeed, no less an eminence than Harry Frankfurt, a distinguished moral philosopher and professor emeritus at Princeton has been quoted (**):

"One of the most salient features of our culture is that there is so much bullshit"

Lies vs bulls**t
But here's the important matter: project success depends on trustful and trusting relationships -- no news there -- and trust, in turn, depends on a track record of truthfulness. Amen to that, to be sure.

Can the bulls**ters be trusted? Are they truthful?
And, in the same vein, what of the liar?
Distinctions without a difference?

Not the same! Not so fast!
If we can pretty well detect bulls**t, and see through to the truth, is there any real harm done?
What about lies?

Frankfurt goes on (paraphrasing):
The essence of bulls**t is that it is produced without concern for the truth. Indeed, it need not be false, even though the perpetrator is faking knowledge (a stopped clock is right at least twice a day). That is, the bulls**ter is indifferent to the truth .... could be right; could be wrong; doesn't care.

The liar, on the other hand, has a very good handle on the truth which he/she purposely tries to hide or obfuscate. Indeed, the liar is quite sensitive to the truth, not indifferent, and wants to lead us away from it.

Caring or not caring
The liar cares deeply about the truth; the bulls**ter doesn't. At the end of the day, who is the greater threat? Frankfurt would have you believe it's the bulls**ter; I'm not so sure.

The bulls**ter, once identified, can be written off to exaggeration, but not willful deceit.
The liar is willfully deceitful.

In my PMO, if I have the insight to choose, I'm going to take the bulls**ter. My idea is that perhaps there is useful person to be rescued, untainted by a willful disregard for truth.
------------------
(*) "On bullshit" by Frankfurt (2005); "On Lying" by St Augustine;  "Your call is important to us; The truth about bullshit" by Penny
(**) Essay: "Say Anything" in the book "When Einstein walked with Goedel" by Holt

---

Buy them at any online book retailer!

Mystery, secrecy, and privacy

---

This blog is not about politics, so we'll keep to the knitting and wax on about mystery, secrecy, and privacy in the project management domain.

For today's screed, I took a few thoughts from an unlikely source of PM advice I found in an 2013 article by Jill LePore entitled "The Prism" (a term in the news of that time)

I, for one, had not thought a lot about the subtle but substantive differences of our three title terms insofar as they have their individual effects on governance, understanding, communications, and perhaps even innovation.

By Ms LePore's reckoning, we can divine the following:

• Mystery is knowledge held by a very few, perhaps only one -- the project's "Almighty" -- with the intent of creating a mystique around the idea or the individual. In other words, the mystical knowledge has no overt operational purpose since it is never to be revealed on acted upon. It's all about aura and mystification.
  
  Politicians love mystery and mystique, isolating them a bit from challenges. Autocrats love mystery too: mystique amplifies power. And, believe or not, the marketing department loves mystique -- mystique sells!
  
• Secrecy is the way we compartmentalize knowledge intended to be acted upon and drive operational outcomes -- but only by a selected few actors.
  
  For whatever reason, secrecy can move the project forward when otherwise acting in a fishbowl with this knowledge is judged to be ineffective... some will be inhibited from full discourse; others embarrassed to show weakness or ignorance; and some will use the information against us.
  
  In business, secrecy often goes by the name "proprietary". In projects, to take one example -- but there are many legitimate examples -- competitive proposals are always held secretly from the competition.
  
  And, the flip side is that if your project is in receipt of proposals from vendors vying for your business, then you need project protocols to protect their competitive secrets.
  
• Privacy is about our own stuff, our own thoughts, and our own biases that we can live with but choose not to share. Although we are social in our relationships, everyone needs their moment and place of privacy.
  (See: issues with open space project space)
  
  Of course, sometimes privacy crosses over into a personal secrecy to compartment things you are doing. That's where the trouble begins because governance, understanding, communications, and perhaps even innovation are surely threatened by personal secrecy just as official secrecy can have debilitating effects.

Bureaucracy begets mystery
Mystery accumulates around bureaucracy, whether intended or not. The larger the structure the more mysterious are those in the head office -- including, by the way, the PMO. Open door policies and other communications are partial anecdotes, but the real anecdote is a flat organization.

Mystery can be a tool
On the other hand, companies exploit mystery to create an aura in the marketplace and enhance their competitive posture, especially on competitive project proposals. Every proposal I ever led had a marketing guy attached whose job was not only to develop information on the competition but also to create mystery in the marketplace -- scaring the competition and attracting the prospective customer.

Secrecy requires definition
Secrecy is about deliberate compartmentalization. And "deliberate" is the operative term. To be deliberate requires definition in advance of the criteria to invoke compartmentalization. In some domains, the requirements and definition come by contract and are imposed on the project. But there's also a lot of proprietary activity -- see pharma R&D for instance -- where corporate secrecy abounds.

Privacy is a late comer
In the genealogy of these things, privacy is a late comer. As mystery became less religious and more secular as Europe exited the Dark Ages, privacy in personal affairs became more of a main stream idea. But in the United States, it did not acquire a legal definition until late in the 19th century. Now, projects have to address privacy issues left and right, and with all manner of cultural and geo considerations. And, the culture of privacy is a shifting ground, so projects are always in a demand-driven mode vis privacy requirements.

In some respects privacy is a wicked requirement: circular, no apparent point of entry, and self conflicting in many respects. No small matter as you try to contain scope, cost, and meet milestones!

---

Buy them at any online book retailer!

Feasibility and risk assessment guide

---

A posting from Matthew Squair put me onto a nice one page pdf template for requirements feasibility and risk assessment.

The chart links compliance, achievability, and technical consequences.

Sidebar:

You could, with just a little effort, build an an interlinking matrix, something like a QFD (quality function deployment) house of quality :

One note:
If you don't recognize the shorthand scientific notation for numbers, like 1.0E-3, this is read as 1 with an Exponent of -3, meaning 1/1000, or 0.001. Similarly, 1.0E+3 is read as 1000. 

Frankly, I would ignore the number rankings. You can make up your own, or have none.

The important content is in the categories and the category definition.

---

Buy them at any online book retailer!

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!