Counter-party risk

---

Define counter-party: 

In a transactional relationship, the other party to -- or participating in -- the transaction is your counter-party.

 

In project situations, there are usually many counter-party transactional arrangements, such as contractors and suppliers with transactional relationships. And within the business there may be transactional relationships among business units and the PMO. 

 

Oh! And don't forget the money: there may be financiers of the business or project which have a counter-party relationship to the project.

Fair enough. But now comes counter-party risk: the risk that the other party to the transaction, or perhaps you yourself, will not be able to hold up their side of the transaction.

 

About counter-party risk

So, you are about to enter into a transaction with another party. What might be the risks?

• Trust: you may not know the other party well enough to convey trust, a willingness to believe what they say without the protections of a written agreement.
• Ability to perform their side of the transaction may be in question. Do they have all the requisite tools, resources, and experience? Is something required of you in order for the other side of the transaction to be completed?
  
• Willingness to perform their side of the transaction when the whole deal comes under stress may require backup

What is your strategy; what are your tactics?

• Your strategy should be to keep the counter-party fully engaged with intent to fulfill their side of the bargain.
• Your tactics should be to put in place standard risk management tools: Written agreements with incentives and penalties; sober assessments of their track record on similar activities; and perhaps insurance for consequential damages if the counter-party fails.
  

---

Buy them at any online book retailer!

Complicated and complex

---

"They" say it's complicated

"They" say it's complex

Are they saying the same thing?

No, actually, there are differences:

• It's complicated if "it" has a lot of parts and pieces
• It's complex if the parts and pieces have a lot of interactions among them, and many of the interactions are not readily apparent, hard to model or predict, and may even lead to chaotic responses 

Good or bad; fix or ignore?

So is complicated or complex a good thing or bad? How would you know? And, what's to be done about them? 

Short answer: Chaos is almost always bad in a system, product, or process -- whatever is the project's outcome. Thus, for that reason alone, complexity may not be your friend.  

But, even without chaotic propensity, complexity is usually not a good thing: complex systems are hard to service; hard to modify; difficult to integrate with an established environment; on and on. If such are present, then complexity is present -- that's how you know.

Complicated is usually a matter of cost: lots of parts begets lots of cost, even if there is minimal complexity. Simple is usually less costly and may not necessarily sacrifice other attributes.

So, what do you do? 

You've read the theory; now, to action:

• Chaos is bad; let's start there. The fix is to reduce complexity. To reduce complexity, a generous number of interfaces are required.
  The purpose of the interface is to block propagation of chaotic responses and contain risk to smaller elements of the system.
  Proof is in the testing. All manner of stimuli is applied to try to induce chaotic responses, and address those that occur. 
  
  
• Complexity is first addressed by interface design; then by service design. To wit: if you have to fix something, how would you separate it from the system for diagnosis, and then how would you repair or replace? Addressing these functional problems will in turn address many of the issues of complexity
  
  
• Complicated means a lot of parts. If that's more expensive than you want to afford, then integrated assemblies will reduce the part count and perhaps address some of the issues of complexity.
  If you've ever looked inside an old piece of electronics circa 1960 or older, you can appreciate the integrated modular design of today's electronics. Hundreds of piece parts have been integrated into a dozen or fewer assemblies.
  

---

Buy them at any online book retailer!

Delusions of vision

---

In this blog and elsewhere, the visionary leader is extolled, aspirational in every respect.

But, what if their strategic vision is delusional?

• From predicates A and B, the leader envisions C
• But, inferring C from A and B is a delusion, unsupported and unsupportable

Perhaps such a delusion is revealed in hindsight, but in the moment who can say C is a delusional inference to be drawn from A and B? How can anyone know that a person is deluding themselves?

There are some signs:

• C is a possibility, yes, but a really long shot by probability
• C is a black swan; there is nothing from history to support C as a consequence of A and B
• C requires new physics, unlikely to ever be realizable
• C requires unusual political support, unlikely to be anyone's political investment
• C is just "confirmation bias" for an outcome wished for but otherwise unlikely

What to do?

So, if your PMO is being led by a leader you think is deluding themselves, what should you do?

 

First, look for your own confirmation bias. Indeed, are you the one that is deluded into thinking the bold and brave is not possible and you look for the supporting evidence to confirm your point of view, discounting ideas to the contrary?

Second, are there others that have the bona fides to not only agree with you but to also speak truth to power about the likely outcomes?

And third, if not C, then what is the inference to be drawn from A and B? Which is the greater error: the cost of accepting C as the objective, or the cost of discarding C and going for C-alternative?

Obviously, all situational. There's no fixed process or recipe.

Did I mention: Good Luck!

 

---

Buy them at any online book retailer!

Coupling, coherence, and other stuff

---

Has someone in your PMO suggested applying a dose of system engineering to portfolio management? If they have, I wonder if they think of it as "three C's and D"?

A bit cryptic? Well, not so much when you spell it out:
Coupling, coherence, cohesion, and diversification

The short form explanation of  three C's and D looks like this:

Here's a little explanation:

Coherence

Coherence is what gives rise to reinforcement and to synergies. Coherence gets its power from phasing and sequencing....in other words, timing. Take 20 people and let them chat at a party and you have--to the macro listener--noise; but phase things correctly and you could have a choir. In other words, from noise a song!

Cohesion

Cohesion is what makes things stick together and perform under stress; to accept tension among parts and keep on going. In a portfolio, it's a matter of making good on the overall business value proposition, and doing so under stress.

The qualitative idea is weak or strong cohesion; ordinarily the metric is strength under stress, which for projects is tolerance for failure.

Strong cohesion means that if one project, or some aspect of a project, fails in some sense, the tensions created among projects because of failed dependencies are not crippling to the business outcomes. Cohesion requires redundant or alternate paths to customer satisfaction through the network of portfolio projects.

Coupling

Coupling is well understood notionally: it's the idea that one effect or outcome directly influences another. Generally, we think of coupling as being loose or tight, referring to how well one effect is transferred onward. Insulation loosens the coupling between outside and inside, etc. 

 

In projects, loose coupling is usually the desired quality. A failure in one project is not coupled into the next is the idea. In portfolios, the same is true. We want high coherence and strong cohesion but loose coupling. And, all three together is sometimes a challenge.

Diversification

Most of us understand diversification from the financial portfolio experience: when one investment is down, another is up, and the overall result is within a range of acceptability. If all investments are really independent of each other, the range of results is compressed by approximately the square root of the number of investments in the portfolio--the square root of N rule.

The same is true of project portfolios. The secret sauce is independence. If coupling is not loose, independence is forfeited, and so also is the power of diversification forfeited.

How to sum up?

Perhaps I'll just say there's a place for system engineering in project management. 

---

Buy them at any online book retailer!

Be Bold; be brave; be calculating

---

I would hardly think today of making my first flight on a strange machine in a 27-mile wind . . .

I look with amazement upon our audacity in attempting flights with a new and untried machine under such circumstances.

Yet faith in our calculations and the design of the first machine, based upon our tables of air pressures, secured by months of careful laboratory work, and confidence in our system of control … had convinced us that the machine was capable of lifting and maintaining itself in the air

— Orville Wright, from “How We Made the First Flight” (*)

I hope you were able to read the last sentence, as long as it is -- my editor would have been apocalyptic!

So, what have we got here with O.Wright's statement that can inform project management?

He begins with audacity! Audacity: "a willingness to take bold risks"
To be audacious! Audacity is a risk attitude that is at first personal, but then infects the whole project culture.

But not recklessly bold risks. Audacious is one thing; willful recklessness is entirely different.

Then comes the skill and science

So then comes the science, the engineering, and the risk management to leaven the audacity. Afterall, as we learn from author Jo Nesbo, "Someone will no doubt come up with an opinion with the benefit of hindsight, but we prefer to be wise in foresight".

In this case, wisdom in foresight requires:

• Calculations and tables of metrics
• Careful laboratory work
• Confidence in the system engineering
• Measurable goal: capable of lifting maintaining itself in air
  

And what does the world get with this elixir of bold thinking, careful consideration of risk, and skill-and-science?

• Heavy machines that fly
• Semiconductors of near atomic size
  
• Electric, hydrogen, and possibly others that upend the transportation industry
• Social media
• Private space travel
• And all the other stuff yet to be envisioned!

----------
(*) Quotation courtesy of Herding Cats

 

---

Buy them at any online book retailer!

Smart and Not-so-Smart

---

Harry’s poker-playing friend claimed that probability theory, and how to play your cards according to the rule book, was the easiest thing in the world.

But what separated smart players from the not-so-smart was the ability to understand how their opponent was thinking ...

Harry Hole, Detective,
according to author Jo Nesbo

Now, in project terms, we would like to think we don't have to worry about opponents. But, of course, that's not the case. Most practical projects at scale have a nemesis, either technical, managerial, or political.

Also, it would be great if we could all grasp "Game Theory" which lays out methodologies for assessing what your opponent is likely to do in the context of what you might be likely to do. [You can read some about this in Chapter 12 of my book, cover illustration below, "Maximizing Project Value"]

In effect "Game Theory" combines probabilities, rules for applying game rules, and methodologies for  making an 'informed estimate' of what others might do.

Stability and equilibrium
If you are working with probability theory in your project, then you are thinking and acting with some uncertainty in mind. As our detective friend says in the opening quote, just understanding some of the 'rules' around uncertainty estimates is not enough.

Coming to some sort of stable (and predictable) position in the project environment is perhaps the most advantageous outcome one could expect in an environment of uncertainty. 

 Perhaps the most practical utility of Game Theory, as applied to projects, is developing equilibrium as a stable and desirable outcome. Odd as it sounds, equilibrium is often achieved by accepting a sub-optimum outcome as a compromise outcome between 'adversaries'. 

And why would you settle for sub-optimum? You settle because the alternative is more costly without compensating benefit.

The "Nash Equilibrium" 

The Nash Equilibrium is an example of such an outcome, and it is explained in Chapter 12. In essence, you and your opponent agree to a compromise plan for which their is no net upside for either of you to divert from the plan. In other words, at the Nash Equilibrium, things are worse for you (and your adversary) if either of you make a change.

The counterpoint is obvious: as long as there are incentives for a more advantageous deal, stability will always be on the knife's edge. Recognizing whether or not you've achieved a Nash Equilibrium may be the smartest thing you can do.

---

Buy them at any online book retailer!

About compartments

---

It's how we all get along, especially in the close quarters of a project team -- even if virtual:

"A well-ordered life has compartments. People that have secrets know that other people have secrets. That's how we all get along

Dialogue from "The Paladin" by David Ignatius

 

Of course, in the pristine description of project methodologies in the PMBOK® and elsewhere, projects are an open book. The project pyramid is transparent from top to bottom; information is readily available.

Real projects are compartmented
I should say that a well-ordered project is strategically transparent but tactically compartmented. Everyone should know and internalize the major mission elements, but tactically, there is value in limitations. 

Effective communication emulates life in a lot of ways, and one of those ways is to compartment information. Immediately, the N-squared number of communication channels between N sources is reduced exponentially.  From that one action, communication quality goes up:

• Fewer rumors, more authoritative information
  
• Less noise, greater signal
  

And, compartmentation is helpful when you need to put space between big egos; separate clashing personalities, and limit people interactions. It's how we all get along.

But also, compartmentation is a tool for limiting information according to sensitivity, proprietary protections, and utility according to function. Sometimes, it's just better to know less, at least with respect to tactical detail.

And, compartments reduce risk.
How so?
In the sailboat business, we speak of "rip stops" in sails. Sails are never one large sheet; they are always compartmented by seams. If a problem arises in one part of the sail, the "rip stop" seam contains the problem, prevents its spread, and usually leaves a lot of the sail useful for powering the boat.

The same goes for a project: compartments are "rip stops". A problem in one aspect of the project is contained, but the rest of the project goes forward.

And, I might add: In system engineering, we build with subsystems linked by carefully constructed interfaces. The interface provides "loose coupling" that helps contain and compartmentalize any issue in one subsystem.

The architecture of project methods
When developing the architecture of your project methodologies, think of what it takes to have a well-ordered project

---

Buy them at any online book retailer!