Leadership by link and buffer

---

"Link and Buffer" is a leadership concept for a leader positioned between a governing board, to whom they must link the project, and a project team which must be buffered from the whims and biases of the board.

Fair enough

But it's not that easy.

In the "link and buffer" space live various skills:

• Vision and practicality: to the board, the project leader talks strategically about outcomes and risks; and about the strategic direction of the project. But, to the team, the leader talks practically about getting on with business. All the tactical moves are effectively smoothed and buffered into a strategic concept which the board can grasp
  
  
• Tempers and angst: When there's trouble, tempers fly. Buffering is a way to decouple. The board's angst does not directly impinge on the project if properly decoupled by the project leader.
  
  
• Personality translation: Few on the project team will know or understand intimately the personalities on the board. Taking the personality out of the direction and recasting instructions into a formula and format familiar to the project team is part and parcel of the buffering.
  
  
• Culture translation: In a global setting, the board may be culturally removed or distant from the project team. Who can work in both cultures? That of the board, and that of the project team? This is not only a linkage task but a translation task to ensure sensitivities are not trampled.

Examples of "link and buffer" abound in military history. Perhaps the relationship between Admiral Ernest King and Admiral Chester Nimitz is most telling. King was in Washington during WW II and was Nimitz superior in the Navy chain of command. Nimitz was in command of the Pacific Ocean Area from his HQ in Hawaii.  

 

King was responsible for a two ocean Navy in a world war; Nimitz more limited. Nimitz was the link and buffer from the tactical fighting admirals at sea, and the strategic war leaders in Washington.  No small matter!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

When mystery is actually progress

---

Got a mystery in your project?

Can't figure out what's happening, or

Can't find the root cause -- after following all the methodologies -- for what you measure or observe?

Perhaps you are making progress!

Stuff happens; don't deny; it's yours to figure out why

Once you do, you may have discovered something quite fundamental about the project outcomes 

There are lots of examples:

• There is a lot of dark matter in the universe; why is there more dark matter than visible matter?
• There are missing particles in the Standard Model of particle physics; where are they?
• Why does the speed of light not conform to Newtonian physics (Einstein worked that out, fortunately)
• Why does your bridge collapse after you built it with a lot of steel?
• Why do team mates fly off the handle when you mention X or Y? (Note: no religion or politics in project teams)

 So, there are a lot of examples. What do you do about it?

• Try Bayes methods of hypothesis testing ... make a prediction (perhaps, gasp!, a guess for lack of something better); test for results; change a parameter and look again. Repeat ....
  
  
• Try models: why does the model work and the system doesn't? (NASA calls something like this 'model based system engineering -- MBSE')
  
  
• Get out of the frame and look from a different vantage point. That's what Einstein did.
  
  
• Try forensic engineering or investigation. This is micro-engineering at the nut and bolt level.
  
  
• Change direction and do something entirely different (not retreat; just advance in a different direction)
  

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Why do they call it a 'black box'?

---

Why do they call it a black box? Maybe it should be just opaque. Either way, it's a system engineering idea:

• Encapsulate a function, 
• Make it opaque and invisible to outsiders
• Feed it inputs and external controls, biases, and offsets (in other words, the 'interfaces')
• Look for and utilize the prescribed outcomes
• Voila! You've got a 'black box'!

Ooops!

What if ...

What if there are chaotic responses, unforeseen resonances, inexplicable outcomes and distortions, and even destructive behavior?

The question is begged: Do you understand how your black box interfaces with your project or system? Very likely if you don't know, the larger system doesn't either because, hey!, you designed the larger system!

If your answer is No to the above, then here's some advice: roll back the black box and expose the functionality to the point you can understand it; you can defend it; you can reliably forecast it's role in your system

Working on AI?

The modern idea of AI with multiple layered meshes of data processors may be the ultimate black box.   If this is your domain, read a bit of this Wired article to get onto my point of view.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

The Four Maths of the PMO

---

Math may not be your favorite thing in the PMO, but hear me out.

There are four 'systems' of math you are probably using without thinking too much about them.

So, if that's so, why think about them now?

• Somebody may use the terminology around you, so informed is better than ignorant
• Communicating with your administrator, analyst, or systems person may be more informed
• You may want to learn more about one or the other, so a look-up of terms is handy

Here's a quick read on the four:

1. Arithmetic and linear algebra: Arithmetic is the add-subtract-multiply-divide thing you have been doing all you life; linear algebra is just using arithmetic in a systematic and rules-based way -- in other words, formulas -- to find some values you might not have but need  (that conveniently lie along straight lines (thus, 'linear')
   
   This is really useful stuff for adding up costs, figuring out schedules durations, and solving for resource unknowns, not to mention (gasp!) working forecast with earned value formulas
   
   
2. Exponentials: See my post on this topic. Exponentials form the world of non-linearity (no straight line). Exponentials are seen in the project office explaining  the non-linear "utility" of the project's value proposition, escalations in communications complexity, discounts for future risks, discounted cash flow (DCF) methods, and other useful stuff
   
   
3. Statistics: Statistics, and its close cousin 'probability', let us deal with uncertainty in project affairs. In this domain, we find 'random numbers': that is, numbers that are a bit uncertain because of incomplete knowledge or because of random effects (for which more knowledge doesn't help).
   
   We can't do arithmetic directly on 'random numbers' because we don't have certain knowledge of what to add or subtract from one random effect to the next. Thus, simulations of statistical effects are the best way to handle such requirements. The 'Monte Carlo' simulation that is built-in to many scheduling apps and some cost and finance apps is an example of handling statistical effects on schedule numbers with simulation.
   
   Keep this idea of 'no arithmetic with random numbers' in mind when people come to you with a risk matrix that purports to multiply random numbers for uncertainty and impact. No can do!
   
   
4. And then there's calculus! You say: 'I can skip this; we don't use calculus in our PMO.' Actually, you do! Calculus is the math of 'change'. And there are always change and changing effects in the PMO.
   
   One powerful idea from calculus is that we can add up the individual effects of change, usually a lot small effects, and we call this process 'integration'. Even more handy, we can specify the integration limits to include only those effects in which we are interested. 
   
   Here's an example of something you probably know about: The so-called "S" curve of accumulating probability. This curve is very handy for assessing confidence limits in risk management. It is actually an integration result straight out of calculus. Small increments of probability from a "bell curve" are integrated to form the S-curve. In other words, if we 'integrate' the "bell curve", the result is the "S" curve!
   
   Of course, the ideas work in reverse: Given the "S" curve, we can 'differentiate' it into the "bell curve" which then provides visualization of central clustering, and visualization of the outliers on the tails where events happen infrequently. 
   
   The secret to understanding derivatives is that they are always ratios: "something per something". If the "per something" part is time, then usually the ratio is a velocity or an acceleration; otherwise it's a density, as in 'parts per million'. The bell curve, being a derivative of cumulative probability, expresses a 'probability density'. 
   
   But maybe you are working in Agile methods and are concerned for 'velocity' and perhaps even the need for 'acceleration' of the evolving product base. Agile product velocity is the "first derivative" of a unchanging base; 'acceleration' is the first derivative of velocity and the second derivative of the original position.

Got it all?

Now you are the PMO math person!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Agile and the sailor's analogy

---

The presentation -- in the link below -- that I gave to PMI some years ago that makes an analogy between sailing a boat and Agile methods is still relevant, and probably will remain so.

Why?

Because a sailing "project" is has much in common with an Agile project:

• Tactics overlay a strategic goal, though there are broadly stated limitations and rules
• Small teams have to work together, or else someone goes overboard
• There's a lot of local autonomy
• Risk is managed locally
• The environment is pretty flat, managerially, but the leader is clearly recognized
• Team success trumps individual success; teamwork is rewarded, particularly in overcoming adversity
• The goal is set by others, but it's obvious to all observers
• The value proposition is clear and present

Have a look:

Click here for a slideshare

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Your project runs on exponentials!

---

When you read stuff like this, you have to wonder: what's this all about?!

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! 

And so it is. Exponentials are the way we bend the project around the corner, or move out quickly. Linear straight-line stuff becomes curved.

Think of it: 

• The future does not have to repeat the past; 
• We can accelerate from where we are now; and 
• Phenomena can -- and will -- die off or slip quietly to an asymptotic finish

What is it?

Technically, an exponent is a number that tells you how many times another number, called the 'base', is multiplied by itself. For example, 2 exp 4 tells us to multiply 2 (the base) by itself 4 times, yielding the number 16. The exponent is sometimes referred to as 'the power'. We might say, '2 to the power of 4'.

Fair enough.

Functionally, it's the multiplying-by-itself thing that bends the curve and creates acceleration in values. In linear arithmetic, the first four products are 2, 4, 6, 8. But in exponentials, the first four products are 2, 4, 8, 16 ; clearly the exponential expression is not linear.

It's common to say: "That's increasing (or decreasing) exponentially". 

What that means is that 'as you move away from the present point, things accelerate quickly'.

Now, for the math inclined or curious, see the footnote at the end of this post.

Consider project 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 x N, or N-squared (an exponential, N with exponent of 2).  

This the heart of the argument -- made famous by Dr Fred Brooks --  that adding more staff to a late project may make it even later, because ....  Because communications become exponentially more complex, and thus less reliable and predictable, as you add staff.

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

Financiers think of risk in terms of the 'rate of return' they demand in order to agree to commit capital to a risky project.

And, this rate of return, "r", is compounded over time. Compounding means that [1 + r] exponentially decreases with the number of compounding periods. The future value is "discounted" to a present value by that decreasing factor.

Consider risk management:

The idea that risk inversely compounds exponentially with time, and thereby discounts the value of future decisions and outcomes is commonly held concept in risk management. 

Other types of risk are subject to exponential effects. For example, the density of probable failures in the future is inversely and exponentially related to a present value of the failure rate. 

Consider the so-called "bell curve"

The 'bell curve' shows us the effects of natural clustering of random outcomes or observations around the mean value.
The actual formula for the curve is non-linear to be sure, and usually we just look up values we are interested in, which for the most part delineate confidence intervals.

But at the core of the bell curve formula's is an exponential expression which is all about how far from the mean is the confidence interval and the point of observation or measurement, i.e: 'distance'-from-the-mean squared strongly influences the confidence intervals of the 'bell curve'.

Consider schedules at the milestone

There is a 'shift-right' tendency at milestones when two or more tasks have to finish together. If the probability of each finishing is 0.9, then the probability of the milestone finishing on time is 0.9 exp N, where N is the number of tasks finishing together. That is a much lower probability of success than any of the contributing tasks.

Consider the random arrival rate of independent actors (events)
Again, the probability distribution of random arrivals is an exponential, and an important concept in certain elements of risk management (Earthquake prediction, to name one, but other types of failures as well). 

Consider 'utility'

All but the simplest concepts of utility are non-linear, and many ideas of utility can be explained or represented with exponentials.

-----------------
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

Footnote for the math inclined or curious:

It's common to think of the number '2' as 2 with an exponent of 1 (any number with an exponent of 1 is equal to itself); and the number '1' is 2 with an exponent of 0 (any number with an exponent of 0 is equal to 1). Other examples: The number '4' is 2 with an exponent of 2; the number '5' is 2 with an exponent of about 2.35, but also 5 is the number 10 with an exponent of about 0.7.

And, a negative exponent is mathematically equivalent to division: 1 divided by the exponential. For example, 0.5 is just 2 with -1 as the exponent, usually written as 1/2.

But here's a limitation of exponent math: there is no exponent that will give us exactly the number '0', although we can get pretty close with an arbitrarily large negative exponent. 

Now the "base" doesn't always have to be '2'. If we change the base to 10, the number 2 is now 10 with exponent of approximately 0.3. (somewhat like there is no exponent that gives us exactly the number 0, there is no exponent of 10 that gives us exactly the number 2. This is the reason that financial reports and other resource reports are not computed with exponential math. Such reports require exact numbers, not approximations)

You may have heard the expression that "things are logarithmic". That's another way of expressing the idea of an exponential. The 'logarithm of 2 (in base 10) is equal to 0.3'. That statement is equivalent to saying '10 with exponent of 0.3 is equal to 2'.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

Hazards to resourcing the critical path

---

In project management school, the lesson on Critical Path includes this rule:

Apply resources first to the critical path, and subordinate demands of other paths to ensure the critical path is never starved.

Beware this hazard: Resources may be real people:

The problem of applying resources arises when we move from the abstract of 'headcount' to the real world of 'Mary' and 'John'. 

Alas! The "resources" are not interchangeable. Mary and John are unique. Consequently, consideration must be given not only to the generic staffing profile for a task but also to the actual capabilities of real people.

Considering Mary and John uniquely

Take a look at the following figure: There are two tasks that are planned in parallel. If not for the unique situation that Mary and John can't be applied to two paths simultaneously, these tasks could be completely simultaneous.

In fact, the critical path could be as short as 50 days -- the length of Task 1. Task 2, as you can see, is only 20 days duration. But for the assignment of Mary and John pushes Task 2 to the right.

But with only Mary and John as resources, the schedule plan stretches out to 65 as shown.

 Here's an idea:

Reorganize the network logic to take into account unique staffing applied to schedule tasks.

Now the schedule plan is shorter, though not as short as it could be if there were resources other than Mary and John. 

And that is actually the embedded lesson learned: With only Mary and John, the two tasks are no longer independent. 

And with a lack of independence, there is a "co-dependency" that is a phenomenon that has to be scheduled also. Thus, we form the rule that interdependency always stretches the plan!

---

Like this blog? You'll like my books also! Buy them at any online book retailer!