Who comes back first?!

---

Ah ha! You are going to reopen the in-person office for the PMO.

Good show!

Ooops! 

Who comes back first? Is there a pecking order? Will there be hurt feelings if you're not picked first? What does that mean, to not be picked first?

And, the other side of that coin: You're picked, but you don't want to go back! Now what? Can you opt-out? What if you do opt-out .... is there a career impact? After all, the big action is often closest to the flag pole.

 

Now you're back and you don't like it! It's just not the same atmosphere; some of the people are missing; relationships are screwed up. Now what? Ask to go back to remote? Can you do that?

Here are the answers:

I don't have any answers. It's all situational, but you shouldn't shoulder all the angst yourself. Find someone to talk with. There many be many fewer demons than first appear.

---

Buy them at any online book retailer!

It's about the sequencing!

---

Sequencing is getting things in a time-order. What comes first; what comes next?

Sequencing is the first task in forming a schedule, but only after you figure out the scope.

 

A before B

If you understand the nature of A and that of B, then if there is a dependency between them vis a vis time order, then getting A done before B sounds easy, but sometimes it makes you wonder!

• Is there a preamble to B that should be done before A is completed?
• Are the resources for A and B in conflict or not available; such could affect the "preamble" activity.
  
• Can B really start after A, or are there other dependencies on the start of B?
  
• Do I really want B to start, or do I want to pause and start C somewhere else? 
• If I start B, immediately after A, have I introduced unnecessary risk or other impacts?
  

Schedule depends on sequence

So, if you're thinking about sequencing, you're probably also thinking about schedule: how long it's going to take?

Or, the other way around: if you are working on a schedule, you have to get the sequence down first. 

 

From time to time, arguments boil up about scheduling tools, like MSProject and others. The usual thinking is that these tools are "so last century" and haven't kept up with more agile planning techniques. 

 

And, worst of all, these older tools promote waterfall (gasp!) scheduling, which is demagoguery for finish-to-start precedence. 

 

Finish-to-start precedence is a sequencing concept. If you pooh-pooh such precedence, I challenge you to put up the roof before the walls are in place.

It's all about the sequencing

First, you have to know what you are going to do. To wit: you can't sequence that which you don't know about, and furthermore, even then there may be sequencing errors you discover once you understand the full extent of the scope.

 

For any project, step 1 is to assemble (or define) the elements of scope by some affinity criteria. (Using the roof-after-walls example, get all the roof stuff in one grouping, and all the wall stuff in another grouping. That way, you can sequence the roof group after the wall group.)

Back to MSProject

MSProject is a good planning tool for sequencing. You can work in the gantt-chart mode and sketch out the big picture pretty rapidly, setting up key milestones as schedule goals. You need not use the precedence mode at all.

However, there is a bridge too far: 

If  you plan in too much detail, MSProject and other such tools are way too tedious to use for maintenance of the schedule once the project is under way. 

 

As a practical matter there will be "mico-dependencies" that crop up, which are worked in real time; micro-loops for feedback and checking results against the evolving construction baseline, etc. that are way too expensive to schedule, status, and maintain as they change.

My advice: at the PMO level focus on the major sequences that drive toward value-add milestones.

---

Buy them at any online book retailer!

The skills stack

---

The skills stack. Heard of it? Somewhat like other stacks of stuff, except the focus is on skills needed in the PMO ... and elsewhere. 

Actually, to me, the description of the stack as provided by strategic thought leader Greg Githens, is less a stack -- which implies an ordering from top to bottom -- and more a flat mesh of interrelated skills. 

 

As used by Githens, one might argue with the term "skill", given that we usually think of skill as some ability specifically learned, practiced, and applied. But, if you expand "ability" into practiced and applied behavior, and also into directed energy and attention, then "skill" in this broader sense is what Githens is getting at. 

 

So, here are three "skills" ... broadly speaking ... I particularly like, as authored by Githens:

... AMBITION, [which] captures an individual’s desire to... achieve their goals.

... ANTICIPATION, [which] is ... looking into the future, knowing that your decisions today will bear their consequences in the future. ...

... REFRAMING, [which] is .... intentionally adopting new points of view and explanations. ...

To this I might add:

• Ambition is typically personal, and often self-centered, but in a larger calling, one could be ambitious to be consequential, to wit: to make a difference that affects others as well as yourself. To be consequential, to have made a difference by your efforts, could be your goal. Why not?
  
  
• Anticipation is certainly looking ahead into the future. A skillful anticipator can assemble a narrative, with its attendant consequences, benefits, costs, and risks, and sequence the tactics necessary to achieve the objective.
  
  
• Reframing is a quite useful skill, often stated as "walk in the other guy's shoes". In effect, step out of your frame of reference and see it from your nemesis', customer's, sponsor's, or partner's perspective, experience, and sense of risk.
  Often, you have to set aside many biases, and reorder priorities in order to skillfully reframe a situation.
  Set aside biases? Really? That's not an easy thing to do. The science of game theory, however, provides some of the tooling that useful for seeing things from another point of view.

---

Buy them at any online book retailer!

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!

All is not a Bell Curve

---

It's a bell, unless it's not
For nearly all of us when approaching something statistical, we imagine the bell-shape distribution right away. And, we know the average outcome is the value at the peak of the curve.

Why is it so useful that it's the default go-to?  Because many, if not most, natural phenomenon with a bit of randomness tend to have a "central tendency" or preferred state of value. In the absence of influence, there is a tendency for random outcomes to cluster around the center, giving rise to the symmetry about the central value and the idea of "central tendency". To default to the bell-shape really isn't lazy thinking; in fact, it's a useful default when there is a paucity of data. 

Some caution required: Some useful stuff in projects is not bell shaped.  Yes, the bell shape does serve as a most useful surrogate for the probable patterns of complex systems, but no: the bell-shape distribution is not the end-all and be-all.

But if no central tendency?
Lots of important stuff that projects use every day have no central tendency and no bell curve distribution. Perhaps the most common and useful is the Pareto distribution. Point of fact: the Pareto concept is just too important to be ignored, even by the "bell-thinkers".

The Pareto distribution, which gives rise to the 80/20 rule, and its close cousin, the Exponential distribution, is the mathematical underpinning for understanding many project events for which there's no average with symmetrical boundaries--in other words, no central tendency.

Jurgen Appelo, an agile business consultant, cites as example of the "not-a-bell-phenomenon" the nature of a customer requirement. His assertion: 

The assumption people make is that, when considering change requests or feature requests from customers, they can identify the “average” size of such requests, and calculate “standard” deviations to either side. It is an assumption (and mistake)...  Customer demand is, by nature, an non-linear thing. If you assume that customer demand has an average, based on a limited sample of earlier events, you will inevitably be surprised that some future requests are outside of your expected range.

Average is often not really an average
In an earlier posting, I went at this a different way, linking to a paper on the seven dangers in averages. Perhaps that's worth a re-read.

So far, so good.  BUT.....

What's next to happen?
A lot of stuff that is important to the project manager are not repetitive events that cluster around an average. The question becomes: what's the most likely "next event"? Three distributions that address the "what's next" question are these:

• The Pareto histogram [commonly used for evaluating low frequency-high impact events in the context of many other small impact events], 
• The Exponential Distribution [commonly used for evaluating system device failure probabilities], and 
• The Poisson Distribution, commonly used for evaluating arrival rates, like arrival rate of new requirements

Even so, many "next events" do cluster
But project managers are concerned with the collective effects of dozens, or hundreds of dozens of work packages, and a longer time frame, even if practicing in an Agile environment.  Regardless of the single event distribution of the next thing down the road, the collective performance will tend towards a symmetrically distributed central value. 

For example, I've copied a picture from a statistics text I have to show how fast the central tendency begins.  Here is just the sum of two events with Exponential distributions [see bottom left above for the single event]:

Good enough
For project managers, central tendency is a 'good enough' working model  that simplifies a visualization of the project context.

The Normal curve is common surrogate for the collective performance.  Though a statistician will tell you it's rare that any practical project will have the conditions present for truly a Normal distribution, again: It's good enough to assume a bell shaped symmetric curve and press on.

---

Buy them at any online book retailer!