Stressed leadership

---

Well, here in the Spring of 2020, leaders are stressed; and circumstances are somewhat chaotic (meaning not only disorganized and counterproductive, but small effects are highly leveraged by exponential responses)

And so one wonders: are our best leaders in crises and chaos likely to have been trained in the military where the 'fog of war' is all too real?

Yes, but no.

Our military schools and for the last 20 years our anti-terror wars have provided ample opportunity to train and experience a large cadre of crises-tested leaders. On the other hand, many such trained people have been summarily relieved for not making the grade.

Indeed, this is no different from wars past: Lincoln famously went through four major commanders before he found his general in Grant. The others were relieved with prejudice. Forward to WW II: ditto: hundreds of combat generals and colonels were relieved for lack of leadership skills in one form or another

On the other hand:
Lincoln was certainly a leader in crises and chaos and never was a military person
Same for Franklin Roosevelt

And the same for many of the squad leaders and battalion chiefs of FDNY that led their men into the Twin Towers; many were not military alumni

And now we have the triage crises in the medical centers making life and death decisions all day long; many not military

And, then there's biology:
Under stress, you're not the same person:

•  Heart rate, blood pressure, and adrenaline all change
• The brain, already a 40% consumer of the body's energy, steps up its energy demand, thereby starving physical functionality and leading to premature exhaustion and other effects (*)

And if you've never really tried to lead under such biological stress, there could be panic attacks. Thus, there is a case for experiencing these effects before you face them in a real leadership demand

What does this have to do with your PMO?
All the following exist in most PMOs in one form or another

• Many elements of leadership can be taught, and thus learned, as part of the project experience
• Some other experience of true high-stress is needed, if only for fending off panic attacks
• Many elements of culture inform leadership: trust, integrity, optimism, to name a few
• Many leaders emerge when the crises builds (so called opportunity model)
• Many leaders instinctively manage risk effectively ... a skill that is not easily taught
• Many leaders manage human relations instinctively ... the right word, and the right emotion to the right target is another hard-to-teach skill

If then you layer on pressure, crises, and chaos to that context, you may get the leader you need.

---------------------
(*) I always tell my ski classes: if your hands are cold, get a warmer hat!

---

Buy them at any online book retailer!

About Exponentials

---

The greatest shortcoming of the human race is our inability to understand the exponential function
- Albert A. Bartlett, The Essential Exponential! For the Future of Our Planet

Sounds profound; what does it mean to the PMO?

Consider communications:
the number of ways that N people (or systems or interfaces) can communicate is N*(N - 1), which for large N is approximately N-squared (an exponential)

Consider project finance:
The present value of future benefits of a project are discounted, exponentially, by the expected risk

Consider the so-called "bell curve" of natural clustering around the mean
The actual formula for the curve is complex, but it's core is the the 'natural number 'e'' raised to an exponential that involves the mean and standard deviation

Consider the decay of natural materials
This also is exponential

Consider the arrival rate of independent actors (events)
Again, an exponential, and an important concept in certain elements of risk management. 

It never ends!
Exponential increases, where the exponent is positive, may work to your advantage, but when the exponent is negative, the phenomenon is decreasing exponentially. Is this good for your project?
Perhaps, but, not so fast!
If the exponent is less than -1, there is a great flattening of the tail, to the point that the thing never ends! Yikes, will this ever be done? (*)

-----------------
If you look up Bartlett's book, you'll find most of the chapters are available free in pdf format
Shout-out to herdingcats for the quotation

(*) Consider the natural number 'e' with exponents 0, 1, -1, -0.1, -0.001, respectively
The values, corresponding, are: 1.0, 2.7 ascending with positive exponent, then descending with negative exponents, respectively: 0.37, 0.9, 0.99, approaching but never reaching 1.0

---

Buy them at any online book retailer!

Game theory in risk management

---

In any moment of decision, the best thing you can do is the right thing, the next best thing is the wrong thing, and the worst thing you can do is nothing. —Theodore Roosevelt

Actually, that's Teddy's version of cousin FDR's famous "Try something!"

But what if it's all about a threat -- something external -- for which you have no experience?

• Call in your PMO team and brainstorm? Perhaps
• Ask the question -- what's the other guy -- the guy doing the threatening -- going to do?

And, if the other guy does X, what's your next move? With that question, you've arrived at 'game theory'

Game Theory and Project Management

Here's the set-up for game theory and project management: As project managers, we may find ourselves challenged and entangled with sponsors, stakeholders, and customers, and facing situations like the following which some may find threatening:

• Adversarial (or competing) parties find themselves entangled in a decision-making process that has material impact on project objectives.
• Adversarial parties have parochial interests in decision outcomes that have different payoffs and risks for each party.
• External parties, like legislators, regulators, or financiers, make decisions that are out of our control but nonetheless affect our project.

• The success of one party—success in the sense of payoff—may depend upon the choices of another.
• Neither party has the ability or the license to collaborate with the other about choices.
• Choices are between value-based strategies for payoff

Game theory is a helpful tool for addressing such challenges.

Specifically, game theory is a tool for looking at one payoff (benefit or risk) strategy versus another and then asking what the counter-party (adversarial, competing, or threat party) is likely to do in each case.

In the game metaphor, “choice” is tantamount to a “move” on a game board, and like a game, one move is followed by another; choices are influenced by:

• A strategic conception of how to achieve specific goals
• Beliefs in certain values and commitment to related principles
• Rational evaluation of expected value to maximize a favorable outcome—that is, a risk-weighted outcome

Tricks and traps

If you look into some of the issues raised by game theory, there are two that are important for project managers

1.  Because you don't know for certain what the other guy is going to do, your tendency is to optimize the balance between your risks and benefits, assuming (or hypothesizing) the other guy has a similar motivation: to optimize risk v. benefit conditioned on what you do.
   In this case, "you update your priors" as new insight into the competition becomes visible.
   
   Actually, this situation is not altogether stable for you, as you've made yourself somewhat hostage to the other guy. And, the other guy likewise. Everything stays in motion.
   
2. Or, you may arrive at a spot, called a Nash Equilibrium, where your choices are irrelevant to the other guy's choices. Thus, the other's choices provide no incentive for you to change your mind.

Challenge yourself to a game

To see how this stuff actually works, challenge yourself to a game. Tricks and traps #1 is demonstrated with this video, "The prisoner's dilemma", and then #2 is the next video in the same series that explains the Nash Equilibrium 

Oh, did I mention this is also Chapter 12 of my book, "Managing Project Value"?

---

Buy them at any online book retailer!

PMO in the construction domain

---

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 important points to grasp:

1. There are generally four day-to-day 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. At a strategic level, you've got the regulators, construction code authorities, and the permitting authorities (And, the latter are often at the bottom of the political food chain involving public planning, zoning, waivers, etc)
3. 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 day-to-day, you'd think the communication channels would be about 15 (using the N-squared minus 1 rule, where N is the number of communicators). That's a lot of cross-talk.

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!

---

Buy them at any online book retailer!

Virtual agile teams?

---

Somebody asked: can a virtual team do Agile?

• 20 years ago, at the dawn of Agile, the answer might have been no. 
• 15 years ago, more less at the peak of the AOL texting app Instant Messenger and the dawn of the smart phone and smart-phone personal networking and conferencing, the answer might have been yes, but with reservations. 
• Now, the answer is "Of course", with some adjustments. 

Here are my thoughts on this.

The communications channel:

Virtual teams often begin by emulating the behavior and circumstances of co-located teams. But can they?

The first thought is communications. Co-located teams can handle a much greater N-squared (*) communication intensity because much communication is person-to-person, and much of person-to-person communication is non-verbal.

(*) What is N-squared?  It's the approximate number of ways objects (people, systems) can communicate. The real formula is N*(N-1). As an example: There are 5*4 ways 5 people can talk among themselves.

Non-verbal face-to-face is a very high bandwidth channel -- speed of light really -- capable of communicating a large information message instantly, although the messages are often highly encoded and subject to inaccurate decoding among strangers or nearly strangers.

Nonetheless, it's much easier to sort out the cacophony of discussion if you can put face and voice and context together. (Anyone who's participated in a large video conference knows the difficulty of segregating voices and getting them associated correctly)

Consequently, when planning for virtual teams, bear in mind that virtual teams don't have the luxury of infinite bandwidth. Even with up to date AV conferencing, the non-verbal is communicated in a lossy channel.

And here's the thing: you don't know how much is lost; one of those known unknowns

Thus, virtual teams need more time in the schedule to compensate for the bandwidth constraints of not being face-to-face.

Velocity impacts:

Some teams relish the hub-bub of real time communications, and others do not. Good practice is to benchmark the virtual velocity before beginning the first iteration. Look for virtual velocity to be slower, and productivity less. 

Perhaps the virtual team needs to be larger, or given smaller bites to work on. (Ooops: Adding people to a slow team makes it slower ... Read: "The Mythical Man month, 20th anniversary edition")


Assigning team work:

Assigning work to virtual teams should follow this simple rule: partition work according to its natural boundaries that minimize and simplify interfaces.

Albert Einstein has been quoted to the effect: "Make everything as simple as possible, but not too simple".

But over simplification is hazardous also. Who's got the "big picture" in mind? The solution can lose cohesion and the bigger picture becomes so obscured that effective solutions are not possible to build from the too-small parts.

Iteration Planning and tracking:

The iteration planning meeting is the agile mechanism for assigning work. All the team's complement attends. The same applies to a virtual team.

Tracking progress and identifying problems:

Only the daily stand-up meeting is affected by the communications unique to virtual teams. The less efficient electronic channels may have to be compensated by extending the time-box of the daily stand-up.

The burn-down and trending data is part of the team scorecard posted electronically as opposed to marking a whiteboard in a team space.

Will it work?
I end where I started:  "Of course", with some adjustments.

---

Buy them at any online book retailer!

When leadership is autocratic

---

Autocrates and autocratic leadership -- on the one hand -- and the classic risk management on the other hand .... is the latter pointless in the context of the former?

And we ask this because:

From essayist Eric Grill writing in the leadership blog of St Thomas University we learn that:

Autocratic leaders typically make all major decisions on their own, with little or no input from others.
Extreme authoritarian leaders often insist on making even minor decisions.

Of course, it shocks the sensibilities to imagine "extreme authoritarian leaders" in a PMO, so for this discussion we'll set micromanagement aside.

But here's an eye opener, also from Mr Grill:

..... autocratic leadership works well in environments that require near-perfect accuracy .....

Software need not apply! The software guys can usually get by with any number of bugs... there's always v2.0

But the other thing is speed:

According to Grill, "Leonard D. Schaeffer considered himself an autocratic leader when he became CEO of Blue Cross of California, saying  'When a business needs to change relatively quickly, it’s much more important to just make a decision and get people moving than it is to take the time to conduct a thorough analysis and attempt to influence others to come around to your way of thinking.' "

Moving on to risk management
The RMO (risk management officer or office), especially in larger projects, is often "staff", and often required by policy rather than a perceived necessity. And, RM comes with these built-in ills:

• RM is not accurate, steeped as it is in statistics and caveats and assumptions, etc
• RM is not speedy, driven as it is by the need to identify threats, develop collection protocols and senors to gather data, analyze, and integrate assessments with context 
• RM is often an opinion by those who don't have the responsibility for outcomes and consequences
• RM is often self-conflicting, given that many have an opinion or an interpretation of the data
• RM, even if correct, often does not alter outcomes

And so, the autocrat, valuing speed, results, precision (in many cases), through-put, and supremely self-confident ignores many staff inputs,  risk management among them (what difference does it make? asks the autocrat)

Or worse, the autocrat can't handle an opinion that differs from their set point of view, having some kind of psychological barrier.  The worst of these are "advisors" who form an opinion and then can't bring themselves to change their mind when new information comes along.

And so what to do if you're the RMO?

• Work on the perceived RM ills (listed above)
• Focus on risks that make a measurable difference to organizational success
• Be persistent pressing your case
• Speak truth to power (if you're inhibited by the autocrat, spend your time on your resume)

---

Buy them at any online book retailer!

State of the practice: Agile

---

I was looking back at some prior essays on Agile and came across the April 2012 PMNetwork magazine. Specifically I was attracted (again) to page 58 for an interview with some agilists on the state of the practice.

Here are a couple of quotes from Jim Highsmith worth tucking away:

Agile project management embraces both “doing” agile and “being” agile—and the latter is the hardest. It defines a different management style: one of facilitation, collaboration, goal- and boundary-setting, and flexibility.

... agile is changing the way organizations measure success, moving from the traditional iron triangle of scope, schedule and cost to an agile triangle of value, quality and constraints.

My take:
Doing agile and being agile: Good insight, but these ideas are certainly agile but not unique to Agile.

• To my way of thinking, all enlightened project managers have been doing this all along, or they should have been.

Now, I certainly agree: Agile calls for a reset of manager's and management's approach (aka style) to projects.

• Fixed price, for a fixed scope, in a fixed schedule is ok if you're in "we've done it before" or some kind of production, but not if you are trying to cure cancer, etc.

Value shift: Agile shifts the discussion from fixed value to best value. And, what is best value?

It's the best the team can do, with the resources committed, towards achieving project goals that will ultimately lead to business success.

Who says what's "best"? In the Agile space, that is a collaboration of the project team, the sponsor, and whoever holds the customer/user's proxy. That's the key:

• The customer/user--through their proxy--gets an input to the value proposition because they may use or buy the outcomes, but the customer/user has no money at stake; it's other people's money, OPM
• The sponsor also gets an input  because it is their money at stake. (The sponsor may be a contracting office, as in the public sector)
• The project team gets an input because they are in the best place to judge feasibility.

Measuring success: Highsmith's second idea is certainly Agile, but it may be too agile for some. Why so? First, there's still "other people's money (OPM)".... . you can't work with OPM and not have metrics of performance to stack up against the money. So, the cost-schedule-scope tension may be hard to manage, but at least there are metrics.

I don't have a problem with another paradigm, say Highsmith's value, quality and constraints, so long as they come with metrics that align with the value that sponsors put on money.

That's why I associate myself with best value: It's OPM with metrics that align with a value proposition leading not only to project success but to business success as well.

---

Buy them at any online book retailer!

Small data is the project norm

---

I've written before that the PMO is the world of 1-sigma; 6-sigma need not apply. Why so? One-time projects don't generate enough data for real statistical process controls to be valid.  To wit: projects are the domain of small data. (Usually)

And so, small data drives most projects; after all, we're not in a production environment. Small data is why we approximate, but approximation is not all bad. You can drive a lot of results from approximation.

Sometimes small data is really small.  Sometimes, we only have one observation; only one data point. Other times, perhaps a handful at best.

How do we make decisions, form estimates, and  work effectively with small data? (Aren't we told all the magic is in Big Data?)

Consider this estimating or reasoning scenario:

First, an observation: "Well, look at that! Would you believe that? How likely is that?"
Second, reasoning backward: "How could that have happened? What would have been the circumstances; initial conditions; and influences?"
Third, a hypothesis shaped by experience: "Well, if 'this or that' (aka, hypothesis) were the situation, then I can see how the observed outcome might have occurred"
Fourth, wonderment about the hypothesis: "I wonder how likely 'this or that' is?
Fifth, hypothesis married to observation: The certainty of the next outcome is influenced by both likelihoods: how likely is the hypothesis to be true, and how likely is the hypothesis -- if it is true -- to produce the outcome?

If you've ever gone through such a thought process, then you've followed Bayes Rule, and you reason like a Bayesian!

And, that's a good thing. Bayes Rule is for the small data crowd. It's how we reason with all the uncertainty of only having a few data points. The key is this: to have sufficient prior knowledge, experience, judgment to form a likely hypothesis that could conceivably match our observations.

In Bayes-speak, this is called having an "informed prior".  With an informed prior, we can synthesize the conditional likelihoods of hypothesis and outcome. And, with each outcome, we can improve upon, or modify, the hypothesis, tuning it as it were for the specifics of our project.

But, of course, we may be in uncharted territory. What about when we have no experience to work from? We could still imagine hypotheses -- probably more than one -- but now we are working with "uninformed priors". In the face of no knowledge, the validity of the hypothesis can be no better than 50-50.  

Bottom line: Bayes Rule rules! 

---

Buy them at any online book retailer!

When the facts change ...

---

"When the facts change, I update my priors"

Dr Bill Hanage of Harvard, as quoted in the press

And so what exactly is he talking about?
Answer: Bayesian statistical methods

The essential matter in Bayes, as different from traditional frequency-of-occurrence statistics is that the starting point is a "guess" leavened by hypothesized or observed conditions.

• The probability of event A, given the apriori conditions of B existing, has a dependency not only probability of B existing, but also the probability of A itself, and the probability that B can exist in the event of A 
• Now, the conditioning of A by the existence or likely existence of B is what is called the "priors"
• If by observation or otherwise it becomes evident that your understanding of B has changed, then an "update to priors" is required, thus bringing about a different understanding of A conditioned on B

That's a lot of words for what is essentially common sense: when the circumstance change, you should change with them, or at least understand the impact if you don't change.

"Update your priors": it's only common sense!

---

Buy them at any online book retailer!

Risk management: what's to know?

---

If you only know one thing about Risk Management, know this:

Schedule slack is your most powerful tool

Poorly developed instincts and skills in the use of this most powerful tool are leading causes of poor risk management

If you are a Systems person --- a strategic thinker; an integrator; a "it all has to work" person -- you'll translate schedule slack into to "loose coupling"

Loose coupling is your most powerful tool

This all sounds like schedule, but the side effects are profound (slack is like a nail; it works everywhere):

• Time is lost to effect design, manufacturing, or delivery mitigation
• Pressures mount to "do something"
• Short-cuts are taken
• The thing may not work at the end (oops, that's career limiting)

And, the list of slack misuse is relatively short, so everyone should be able to keep these bullets in mind:

•  It shall be: All schedules require slack; a schedule without slack is but a hope, and is risky all the way
  
• At the end: Slack is always sequenced after a risky event is to occur. NEVER put the slack first, hoping it will all go away
• Don't add risk unwittingly: Unnecessary coupling (to wit: bundling) just adds risk where there was none. Decouple everything; don't purposely couple anything. 

If you bundle (tightly couple) the statistics are against you:

• If two independent events have a 9-in-10 chance of success, then when tightly coupled and no slack between them, success of the pair is only 8-in-10, a loss of 10 points
• It gets worse fast: a pair with 7-in-10 chance of success degrades to less than 1-in-2. A loss of 20 points.  Good grief!

The effect of slack? NO loss of points .... a cheap way to fight  

---

Buy them at any online book retailer!