My backlog is blocked!

---

Yikes! My backlog is blocked! How can this be? We're agile... or maybe we've become de-agiled. Can that happen?

Ah yes, we're agile, but perhaps not everything in the portfolio is agile; indeed, perhaps not everything in the project is agile.

In the event, coupling the culprit

Coupling? Coupling is system engineering speak for transferring one effect onto another, or causing an effect by some process or outcome elsewhere. The coupling can be loose or tight.

• Loose coupling: there is some effect transference, but not a lot. Think of double-pane windows decoupling the exterior environment from the interior
• Tight coupling: there is almost complete transference of one effect onto another. Think of how a cyclist puts (couples) energy into moving the chain; almost none is lost flexing the frame.

In the PM domain, it's coupling of dependencies: we tend to think of strong or weak corresponding roughly to tight or loose.

The most common remedy is to buffer between effects. The effect has to carry across the buffer. See Goldratt's  Critical Chain method for more about decoupling with buffers

But buffers may not do the trick. We need to think of objects, temporary or permanent, that can loosen the coupling from one backlog to another (agile-on-agile), or from the agile backlog to structured requirements (agile-on-traditional).

With loose coupling, we get the window pane effect: stuff can go on in environment A without strongly influencing environment B; this is sort of a "us vs them" approach, some might say stove piping.

Obviously then, there are some risks with loose coupling in the architecture that bear against the opportunity to keep the backlog moving, to wit: we want to maintain pretty tight coupling on communication among project teams while at the same time we loosen the coupling between their deliverables.

There are two approaches:

• Invent a temporary object to be a surrogate or stand-in for the partner project/process/object. In other words, we 'stub out' the effect into a temporary effect absorber.
• Invent a service object (like a window pane) to provide the 'services' to get from one environment to another.

Of course, you might recognize the second approach as a middle layer, or the service operating system of a service-oriented-architecture (SOA), or just an active interface that does transformation and processing (coupling) from one object/process to another.

With all this, you might see the advantages of an architect on the agile team!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

GIGO ... or quality in; quality out

---

Garbage in; garbage out... GIGO to the rest of us

Re GIGO, this issue is raised frequently when I talk about Monte Carlo simulation, and the GIGO thing is not without merit. These arguments are made:

• You have no knowledge of what distribution applies to the uncertainties in the project (True)
• You are really guessing about the limits of the three point estimates which drive the simulation (partly true)
• Ergo: poor data information in; poor data information out (Not exactly! the devil is in the details)

Here are a few points to consider (file under: Lies, damn lies, and statistics):

Who care about the distribution?
First: There's no material consequence to the choice of distribution for the random numbers (uncertain estimates) that go into the simulation. As a matter of fact, for the purposes of PM, the choices can be different among tasks in the same simulation.

• Some analysts choose the distribution for tasks on the critical path differently than tasks for paths not critical.
• Of course, one of the strengths of the simulation is that most scheduling simulation tools identify the 'next most probable critical path' so that the PM can see which path might become critical.

Re why the choice is immaterial:  it can be demonstrated -- by simulation and by calculus -- that for a whole class of distributions, in the limit, their infinite sum takes on a Normal distribution.

• X(sum) = X1 + X2 + X3 +.... +XN, where N is a very large number, X(Sum) is Normal, no matter what the distribution of X is

As in "all roads lead to Rome", so it is in statistics: all distributions eventually lead to Normal. (those that are practical for this purpose: single mode and defined over their entire range [no singularities]),

To be Normal
To be Normal, or normal-like, means that the probability (more correctly, the probability density function, pdf) has an exponential form. See: Normal distribution in wikipedia

We've seen this movie before in this blog. For example, few uniform distributions (not Normal in any respect), when summed up, the sum took on a very Normal appearance. And, more than an appearance, the underlying functional mathematics also became exponential in the limit.

Recall what you are simulating: you are simulating the sum of a lot of budgets from work packages, or you are simulating the sum of a lot of task durations. Therefore, the sim result is summation, and the summation is an uncertain number because every element in the sum is, itself, uncertain.

All uncertainty is distributed... no point solution
All uncertain numbers have distributions. However, the distribution of the sum need not be the same as the distribution of the underlying numbers in the sum. In fact, it almost never is. (Exception: the sum of Normal is itself Normal) Thus, it really does not matter what distribution is assumed; most sim tools just default the Triangular and press on.

And, the sim also tends to discount the GIGO (garbage in/garbage out) problem. A few bad estimates are likewise immaterial at the project level. They are highly discounted by their low probability. They fatten the tails a bit, but project management is a one-sigma profession. We largely don't care about the tails beyond, certainly not six sigma!

Second: most folks when asked to give a 3-point simply take the 1-pointer they intended to use and put a small range around it. They usually resist giving up anything so the most optimistic is usually just a small bit more optimistic than the 1-pointer; ....  and then they put something out there for the most pessimistic, usually not giving it a lot of thought.

When challenged, they usually move the most-likely 1-pointer a bit to the pessimistic side, still not wanting to give up anything (prospect theory at work here). And, they are usually reluctant to be very pessimistic since that calls into question the 1-pointer (anchor bias at work here). Consequently, you get two big biases working toward a more optimistic outcome than should be expected

Bias can be overcome
Third: with a little coaching, most of the bias can be overcome. There is no real hazard to a few WAG because unlike an average of values, the small probability of the tails tends to highly discount the contribution of the WAGs. What's more important than reeling a few wild WAGs is getting the 1-pointer better positioned. This not only helps the MC Sim but also helps any non-statistical estimate as well.

Bottom line: the garbage, if at the tails, doesn't count for much; the Most likely, if a wrong estimate, hurts every methodology, whether statistical or not.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Scheduling ... how did we get here?

---

Patrick Weaver gave a talk at Primavera06 about the history of scheduling. His talk is captured in an interesting paper: "A brief history of scheduling: back to the future"

Patrick is somewhat of a historian and prognosticator on matter such as these. He also has written:

• The Origins of Modern Project Management: www.mosaicprojects.com.au/Resources_Papers_050.html
• ‘Trends In Modern Project Management - Past Present & Future’www.mosaicprojects.com.au/Resources_Papers_061.html
• ‘Seeing The Road Ahead – The art of presenting schedule data effectively’www.mosaicprojects.com.au/Resources_Papers_106.html   

So, what is the history of scheduling? I certainly remember the days of yester-year before MSProject and its adult cousin Primavera; I remember when the only scheduling tool I had was graph paper, and I remember when the mainframe scheduling tools began to replace hand-drawn bar chart schedules and simple networks.

Weaver writes:

Modern schedule control tools can trace their origins to 1765. The originator of the ‘bar chart’ appears to be Joseph Priestley (England, 1733-1804); his ‘Chart of Biography’ plotted some 2000 famous lifetimes on a time scaled chart “…a longer or a shorter space of time may be most commodiously and advantageously represented by a longer or a shorter line.”

Priestley’s ideas were picked up by William Playfair (1759-1823) in his ‘Commercial and Political Atlas’ of 1786. Playfair is credited with developing a range of statistical charts including the line, bar (histogram), and pie charts

We learn these additional nuggets:

• The science of ‘scheduling’ as defined by Critical Path Analysis (CPA) celebrated its 50th Anniversary in 2007.
• In 1956/57 Kelly and Walker started developing the algorithms that became the ‘Activity-on-Arrow’ or ADM scheduling methodology for DuPont.
• The PERT system was developed at around the same time for the US Navy's Polaris missile program 
• PERT lagged CPM (Critical Path Analysis) by 6 to 12 months (although the term ‘critical path’ was invented by the PERT team).
• Later the Precedence (PDM) methodology was developed by Dr. John Fondahl; his seminal paper was published in 1961 describing PDM as a ‘non-computer’ alternative to CPM.

Of course, one of the most profound developments was the arrival and market penetration of the low cost PC-based personal scheduling tools like MSProject. In Weaver's view that made schedulers out of everyone, but everyone is not a scheduler, or can even spell the word.

In my personal opinion, the integration of Monte Carlo tools with low cost scheduling applications like MSProject was equally profound. The MC simulation "fixes" some of the most egregious problems with PERT and the simulation idea has largely run PERT into obsolescence. The main thing that PERT does not handle well is schedule joins or merge, and the statistical merge bias that goes with it.

On the dark side, MSProject has profoundly muddled the whole idea of the WBS. The fact that one of the fields in MSP is called "WBS" is most unfortunate. There are a whole generation of project analysts who believe they created a WBS by the simple act of making that field visible. Not so: schedule is the "verbs" of the project; WBS is the "nouns". Together, WBS + schedule = project narrative.

Now, in Weaver's view, we return to the future:

The changing role of the scheduler has been almost as interesting:
• The mainframe era saw scheduling as:

• A skilled profession
• Central to the success of projects

• Then came the PCs…… everyone and no-one was a ‘scheduler’ in the 1980s and 90s
• However, in the 21st century, the new ‘enterprise’ era sees scheduling as:

• A skilled profession
• Central to the success of projects

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

An introvert can lead

---

The introverted leader: is this an oxymoron? In my experience: definitely not. And, my experience aligns well with Susan Cain's popular book Quiet: The Power of Introverts in a World That Can't Stop Talking

And by introverted, we mean: Someone who gets more energy out of quiet time--loner time, even if in an open plan--than they do mixing in a group. Indeed, mixing in a group discharges an introvert. An extrovert is just the opposite: they discharge during loner times and charge up by absorbing the energy of the crowd.

My definition certainly doesn't mean an introvert is paralyzed by public speaking, can't socialize, or draw from a group/team/crowd. Far from it: some introverts are quite eloquent in public, very approachable, and get a lot from a group experience.

I like to talk about the professional extrovert and the private introvert. Extroverts are often the rewarded ones, the admired, and the influential. So, private introverts train themselves to be extroverts.

In the professional setting, you may be hard pressed to pick out the introverts until you notice who leaves first: they do. When they become discharged, they simply leave to get the recharge from the loner setting.

And, they can be good leaders. James T. Brown writes (in his book "The handbook of program management") that to be a good leader, “a program manager needs to have an ingrained sense of organizational mission, must lead and have the presence of a leader, must have a vision and strategy for long-term organizational improvement, must be a relationship builder, and must have the experience and ability to assess people and situations beyond their appearances.

PM Brown says nothing about being a natural extrovert, a professional extrovert, or really anything of personality, except for "presence of a leader". In other domains, this is called "command presence", the aura of confidence that naturally attracts those looking for direction, safety, order, and back-up.

 "They" say that some of our most notable Presidents of the US  have been introverts....a job that requires an extraordinary public appeal--usually a bane of introverts--to get elected in the first place and remain politically popular and influential once in office. If so...my case is made.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Risk: four points of view

---

1

Frequency-impact: When you say "risk management" to most PMs, what jumps to mind is the quite orthodox conception of risk as the duality of an uncertain future event and the probability of that event happening.

Around these two ideas -- impact and frequency -- we've discussed in this blog and elsewhere the conventional management approaches. This conception is commonly called the "frequentist" view/definition of risk, depending as it does on the frequency of occurrence of a risk event. This is the conception presented in Chapter 11 of the PMBOK.

The big criticism of the frequentist approach -- particularly in project management -- is that too often there is no quantitative back-up or calibration for the probabilities -- an sometimes not for the impact either. This means the PM is just guessing. Sponsors push back and the risk register credibility is put asunder. If you're going to guess at probabilities, skip down to Bayes!

However.. (there's always a however it seems), there are three other conceptions of risk that are not frequentist in their foundation. Here are a few thoughts on each:

2

Failure Mode Event Analysis (FMEA): Common in many large scale and complex system projects and used widely in NASA and the US DoD.  FMEA focuses on how things fail, and seeks to thwart such failures, thus designing risk out of the environment. Failures are selected for their impact with essentially no regard for frequency. This is because most of the important failures occur so infrequently that statistics are meaningless. Example: run-flat tires. Another example: WMD countermeasures.

3

Bayes/Bayes theorem/Bayesians: Bayesians define risk as the gap between a present (or more properly 'a priori') estimate of an event and an observed outcome/value of the actual event (called more properly the posterior value).

There is no hint of frequentist in Bayes; it's simply about gaps -- what we think we know and what it turns out that we should have known. The big criticism -- by frequentists -- is about the 'a priori' estimate: it's often a guess, a 50/50 estimate get things rolling.

Bayes analysis can be quite powerful... it was first conceived in the 17th century by an English mathematician/preacher named Thomas Bayes. However, in WWII it came into its own; it became the basis for much of the theory behind antisubmarine warfare.

But, it can be a flop also: our 'a priori' may be so far off base that there is never a reasonable convergence of the gap no matter how long we observe, or how many observations we take.

4

Insufficiently controllable, aka anonymous operations: the degree to which we have command of events. Software, particularly, and all anonymous systems generally are considered a "risk" because we lack absolute control. See also: control freak managers. See also the move: 2001: A Space Odyssey. Again, no conception of frequency.

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Be consequential

---

Interviewer: "Yes, I hear all of that. But what did YOU do?"
This is your moment to explain how consequential you were on the last job, or throughout your career.

The test, of course, is what footprints in the sand did you leave behind? But for your efforts, imagination, leadership, first responses, etc, something of consequence would not have happened, or might not have happened.  What was that?

Not all invention
Managers are particularly susceptible to the "But what did YOU do?" question. Just keeping things moving may be of consequence, but often, when looking back, it's hard to find the value-add in routine managerial tasks.

Sometimes being consequential yourself is motivating, inspiring, encouraging, and enabling others; sometimes being consequential is providing for the "welfare" of others by providing jobs, careers, environments, and relationships.

Add value
At the end of the day, you yourself have a lot to says about your own job content. Unsurprisingly, you can grab for the ring more often than you think. I think the test is always about adding value:

• If you didn't make the customer more successful, why should they pay?
• If you didn't make the customer more successful, they may not be able to pay.
• If you didn't make the customer more successful, what did you do instead?

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

J.Q. Adams on leadership

---

J.Q. Adams was the 6th president of the United States -- a one-term guy who lost to populist A. Jackson in the election of 1828.

Apart from that distinction he had a pithy thought on leadership, which I pass along hither:

If your actions inspire others to dream more, learn more, do more and become more, you are a leader."

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The price of value?

---

It's commonly said "value is in the eye of the beholder", meaning: the price of value is what someone is willing to pay.

Fair enough. No willing buyer: no practical value. Many potential buyers: let demand drive the value (Some would call this phenomenon bubble economics .... perhaps)

If the market is "efficient" --  meaning everyone has access to all the relevant information -- then value, like water, should find it's own level.

Then, along comes this idea, usually tagged to an intangible:

"There is no right or wrong value. Value is only a matter of adoption and enthusiasm"

In other words: there's no comparable benchmark. The intangible is what it is to those who want it for whatever the reasons.

Now comes project management: How do you build a business case around outcomes with no benchmark; no idea of a right value -- whether too high or too low?

Answer: it's a crap shoot, and such risk separates the bold from the timid. No need to write a book for a business case; you can probably fill it out on a post card.

Perhaps the business can generate its own wind, stirring up demand (I didn't know I needed that!) where there is none, driving both adoption and enthusiasm. But, sometimes both just take off: the smart phone didn't need much of a kick!

Others:

• Sony Walkman comes to mind, but it's a tangible. Similarly the personal computer. Who knew you needed a computer in your house ... didn't they belong in the rooms with the punch cards -- don't fold or staple?
• Digital currencies come to mind. How do they work and what are they worth? And, who says the worth is this or that?

Since there are no objective answers to any of this, I can leave it here!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The real problem?

---

"I cannot define the real problem, therefore I suspect no real problem, but I'm not sure there's no real problem"

Richard Feynman, Theoretical physicist

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Happy New Year!

---

Happy New Year!

---

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog