Sunday, July 14, 2019

Soccer for 3 year-olds

Ever been to a soccer match with 3 year-olds on the field?

All go for the ball all the time; it's just a herd moving around the field (*), more or less with ball the center of attention. But, little is done except to kick at the ball. And certainly no one is ready for the breakout.

And this applies to project management how?

The best example is email with the dozen addressees. Everyone gets the "ball" but actually no one gets the ball. "Hey, everyone was supposed to do something!" But actually, no one did anything but kick it around.

It's like 3 year-olds playing soccer!

(*) field = pitch to some

Buy them at any online book retailer!

Thursday, July 11, 2019

Oceans to fly

Everyone has oceans to fly, if they have the heart to do it. Is it reckless? Maybe. But what do dreams know boundaries?
Amelia Earhart

This month we celebrate the Apollo program and the flight of Apollo 11 specifically, the first man-to-land-on-moon mission completed 50 years ago this month. (*)

Surely Apollo was our ocean of the times, 50 years ago.

And, coming only 11 years after the U.S. launch its first satellite in January, 1958 -- the so called "grapefruit" -- Apollo was certainly reckless in a certain kind of way, myriad risks taken in order to meet the timeline set by President Kennedy to get to the moon by the end of the 1960's.

(*) Launched July 11, 1969; moon landing July 20, 1969

Buy them at any online book retailer!

Monday, July 8, 2019

A historical perspective

The future may not repeat history, but it rhymes
No linearity
Another way to understand the opening witticism is that activities guided by people aren't amenable to linear -- that is, straight line -- projections and forecasts. But they are often close

Fair enough ... most would agree. Experience keeps us between the lines, as it were.

The upshot is that using the facts of history to forecast the randomness of the future requires the forecast to be probabilistic -- that is: needs to allow for a range of outcomes, subject to the biases, experience, pressures, and circumstances that inform human activity -- in the moment.

Repeat vs Rhyme
Linear projections of the past history or performance into the future usually are wide of the mark. Why? Because the very projection itself stimulates a counter-strategy. Thus no repeat!

But, projects are rarely a green field, so there are historically defined limits -- process, culture, experience. Thus, the future rhymes with the past, even if not repeated.

Project manager's mission:
Among several possible mission statements is this one (*):

The mission of the project manager is to defeat forecasts that imperil delivering expected value within the bounds of reasonable risk 
Perhaps you can see the rhyming effect of that statement .....

(*) See page 2 of this blog for a more complete explanation of the project manager's mission

Buy them at any online book retailer!

Thursday, July 4, 2019

4th of July

This office is closed on 4 July due to circumstances beyond our control
Sign on British Consulate in the USA

Buy them at any online book retailer!

Monday, July 1, 2019

Sacred but not immutable

There are a lot of project principles, and processes built on those principles, we think of as immutable: stationary--and proven--with time, experience, context.

Somewhat like the speed of light: Every observer or practitioner in any frame would see them the same way

Not so fast!

Sacred indeed! To be respected? Yes! Defaults that are best practice? Absolutely
But immutable? No.

Unlike the speed of light, Planck's constant, the G-gravitational constant, and a few others, everything else is subject to interpretation, framing, circumstances and context, and the advance of process improvement.

To be immutable in the project context is to be on the edge of denying "new physics" that might move the PMO to a more effective plane

New under the Sun
Just during my professional PM time, I've witnessed:
  • Theory of Constraints
  • TQM in multiple forms, largely abandoned
  • Critical chains
  • Agile methods
  • Monte Carlo simulations into the main stream
  • PERT dismissed
  • Iron triangles, parallelograms, and other interdependencies
  • Black Swans and other physics of the unknown (chaos, fragile systems etc)
  • Risk matrix
  • Etc

Buy them at any online book retailer!

Sunday, June 30, 2019

Agile -- what it means

Dilbert: We need 3 more programmers.
Boss: Use agile programming methods.
Dilbert: Agile programming does not mean doing more work with less people. 

Boss: Find me some words that do mean that and ask again

Dilbert is a creation of Scott Adams
And so, you might ask: what does agile mean?

How about this?

Agile means getting effective project results even in the swirl of complex and uncertain project requirements, primarily by applying small teams, working collaboratively, to deliver increments of business value, with priority according to business effectiveness, importance, and urgency
Ooops! I seem to have left out anything about process. Is agile a process-free zone? Of course not! No one does anything functionally without applying a bit of process, even if it's only two steps.

My observation -- and personal experience -- with myriad small teams is that they self organize to optimize their self interests amazingly fast, first trying one process -- perhaps a baseline process -- and then quickly shifting to another to find a "local" optimization. Sometimes there's an obvious leader; sometimes it's all for one; one for all.

When/where collaboration improves their lot, they'll readily collaborate. Where it's problematic is when collaboration demands are laid on top-down with no obvious improvement in the local process and no apparent connection to goals or objectives. If the top-down thing is legitimate, then the project leadership needs to get in the communications mode to show how all the dots connect! 

Buy them at any online book retailer!

Friday, June 28, 2019

Decisions on auto-pilot

[Some decision analysis'] have been going on for long enough that they've built up their own speed and force. ... We call them decisions, but they really aren't. [They are] the sum of so many previous events and determinations that they have a weight that feels like a layer of time
David Ignatius
"We call them decisions but they really aren't".
The worst variety of such auto-pilot decisions is trying to rescue or justify "sunk cost", to wit: we've invested so much that we can't afford to decide anything else but to keep going 

Invested in vain
"Sunk Cost" is the cost already expended for which you can't recover. It's no basis for a decision. Decisions should be made on the outcomes to be had by further investment: the ROI on the future.

Of course, easy to write this; harder to execute. No one wants to be embarrassed or fired over wasted or abandoned effort and cost. No one wants to explain a sacrifice or supreme effort made in vain

Advance in a different direction
But a Marine general in Korea, circa 1950, was heard to say (or so he was alleged to have said): "Retreat, hell! We've advancing in a different direction"

Sometimes that's the decision to be made in spite of "...  a weight that feels like a layer of time"

Buy them at any online book retailer!

Tuesday, June 25, 2019

"Open" risk management

To be open
Every text and paper I've read describes risk management like many other project processes: open, transparent, available to any on the project team. Risks are identified, evaluated, ranked, made subject to some form of risk reduction paradigm; and everyone is made aware.

Oh, but if it only were!
Most of us can handle the text book process. It's more will than capability

But, on projects of material consequence, the "real" risk management is not open
The "real" stuff begins when the text book processes have run their course

Or, not to be open
Too often than not, risks are compartmented. Sometimes "innocently" because the related work and scope are compartmented by project circumstances: security; systems partitioning; backlog partitioning; teams and teamwork; virtual teams

Judgments scorned as guesses
Only bring facts! Ooops, there are no facts about the future; only assessments of events, impact, and probability. All the facts are in the history.

No facts? Then you're just guessing, "they" say. So, "they" say: take you guesses elsewhere.

Inconvenient assessments
But, then, of course, there's the inconvenient assessments that need to be "buried". These assessments come to the wrong conclusion or forecast; they are not in accord with company or agency politics. Sometimes it just petty professional competitions

Whatever: of these we can say that risk management is "closed", not open; not transparent; and not available to all who need to know

Bummer !

Buy them at any online book retailer!

Saturday, June 22, 2019

Who calls anymore?

Who calls anymore? Some, but many fewer than before .... unless it's a robo call

It's surely not news that a lot of business communication has moved to the text and email.
Fair enough

But, that leaves much more communication open loop and unacknowledged than is/was the case with the telephone call.
That may not end well. Such open loop communications violates basic control-loop theory. To wit,
to have predictable outcomes, the loop should close on the sender as a means of confirmation of message received.

So now, as non-verbal correspondents, we have the responsibility of upping our game.
Some help is found in the essay "How to get every email returned"

From that essay and my own experience, my advice is this:
  • Keep it short!
  • Write in bullets where ever possible.
  • Don't exaggerate ... when discovered this kills your credibility
  • Don't guess; meaning: say only what you know
One troubling assertion in the essay: Emotion is more persuasive than facts.
Perhaps; it depends

I worked for a few years for a Asian company with Asian managers. Culturally, those managers put more emphasis on facts than comparable American managers. In my experience, Americans were/are more tolerant of ambiguity, uncertainty, hunches, instincts. Often, these are wrapped in emotion

One last point, circling back to closing the loop:
  • Ask for acknowledgement. Often, the "open-loopers" are unaware of the poor practice of not closing with their correspondent

Buy them at any online book retailer!

Wednesday, June 19, 2019

Understood ... misunderstood

The blog at herdingcats provided this little bit of wit:
Don't write so that you can be understood, write so that you can't be misunderstood. — William Howard Taft
Taft has a good point there:
  • Not only to be understood (meaning + context) 
  • But to not be misunderstood (meaning + context + motivations or expectations)
Not so fast!
It's often not that simple

You want not to be misunderstood:
First, for understanding, start with the three step process for communications

To be understood, steps 1 and 2:
1. Tell 'em what you're going to tell them
2. Tell them

To not be misunderstood, step 3:
3. Tell them what you told them

Second, to avoid misunderstanding, deal with these hazards:
  • Missing or ambiguous antecedents (Pronouns should be banned! Be specific with names, as example: Tom and Jerry wrote the report. But there were complaints about the analysis that was done; he should have done it more carefully)
  • Big words not commonly understood (intellectual arrogance) 
  • You've got in your head, but you don't get it down on paper (and you don't know you didn't get it down on paper)
    Typically the context or connections with prior thoughts are missing on paper.
    The best way to address this missing material: compose the words now and read them a day later .... does the wording still make sense?
You want, or can tolerate, misunderstanding by some, but not all
You don't want your intended correspondent to misunderstand, but it's ok if everybody else misunderstands, even as they seemingly understand.
  • In politics: plausible denial (everyone's favorite go-to). The words are understood, even as the intended understanding -- deliberately open to misunderstanding -- is obscure. (Make them an offer they can't refuse)
  • In security: You and I have the code for the plain text, but others see and understand the coded text differently.
    As example: Coded text, i.e. what the world understands: "Play the piano"; Plain text (what you and I really understand): "Start the process"
  • In command and control: interpretable instructions or vision. To wit: strategic wording written down, but implementing details and interpretations left to others
    (In effect, delegation to the tactician or field commander. But sometimes you let interpretation "live" with the times and circumstances [so-called "living documents"])

Buy them at any online book retailer!

Sunday, June 16, 2019

Manage the white space

You've got a team to manage; until you don't
Keeping the team together promotes cohesiveness, intra-team loyalties, and productivity (no investment required to introduce new players and relationships). But, if there's too much slack -- i.e. downtime or "whitespace" --  you might lose your team.

But, keeping you team begs the question: How to keep everyone busy all the time so as to fend off raiders looking for resources?  In the popular vernacular of project management, keeping everyone productively busy means actively managing their downtime, aka 'white space', between and amongst their planned activities.

Whitespace methodologies
In organizations that are aggressively matrix managed, one approach to 'white space' management is to reassign people to another project with the intention of just a short assignment to 'keep them off the overhead' and always on 'billable hours'.  Of course, such practice breaks up the team for a short time so it kind of flies in the face of cohesiveness, team accomplishment, and team metrics.

And, aggressive matrix management assumes the F.W. Taylor model of management science: jobs can be filled by anyone qualified for the job description... interchangeable parts, as it were. In the era of team work where teams recruit their members, Taylorism is an anathema. Thus, aggressive matrix management is likewise seen as anti-team.

That all brings us to another approach -- more popular these days -- which is: manage the white space by managing the team backlog.
  • Make sure that the backlog has all the technical debt and low priority requirements present and accounted for so that they can be fit to the white space opportunity.
  • Develop and maintain a "parking lot" for off-baseline opportunities that might fit in the white space
  • So also bring in mock testing, special event prototyping, and, of course, that bane of all:
  • Maintenance of team records.
What does it cost?
One consequence of managing by teams: the cost is known, predictable, and relatively fixed. Each team has a running cost, and so the total cost closely approximates the sum of the number of teams x the running cost of each.

Affordable value
Of course, is the team affordable? Many PMs are not comfortable with the project staff being a fixed cost. They would much rather have more granular control. I get it, but the here's the main point about cost:
The cost of a project is not its value; in a "good project", value greatly exceeds cost

Buy them at any online book retailer!

Thursday, June 13, 2019

Risk: the second thing you do

Managing risk?
Can you imagine there's risk to manage?

Here's the second thing you do:
  • Evaluate the slack ... 
What's to evaluate?
  • You might think the most important thing about slack is how much is there; what do I have to work with? Nope
  • Whatever you've got, the most important thing is sequence and position. Where in the course of events are you going to position slack so that it works to your greatest advantage?
Slack makes the first thing possible
  • We all know that the first thing in risk management is loosen the coupling.
  • Slack is the mechanism for such loosening
Where to position slack?
  • At the end (of a schedule or task)
  • Between joins of physical units (if expansion allowance is necessary)
  • Wherever timing is critical
It's not to wasted
Apart from overly tight coupling, poor positioning or sequencing of slack is a resource wasted. And, it will cost you otherwise to substitute an alternate resource!

Buy them at any online book retailer!

Monday, June 10, 2019

Performance; experience; wisdom; track record

 “You do not write your life with words...You write it with actions. What you think is not important. It is only important what you do.” (*)
Patrick Ness 
What you do adds up
Getting promoted? Hopefully not to your level of incompetence!
Want to get promoted? Most do.

What's needed: a personal track record; as Ness would say: a record of what you do.
  • Personal performance over time
  • An accumulation of experience
  • Demonstration of wisdom
About wisdom and experience
Hopefully, you recognize the linkage of the last two: wisdom derives from experience, but wisdom only derives from the experiences of both success and failure
“By three methods we may learn wisdom: First, by reflection, which is noblest; Second, by imitation, which is easiest; and third by experience, which is the bitterest.”
About performance  
Laurie Harvey has an idea on this: KPIs for success , meaning KPIs for personal success as a project manager. In her essay, Harvey makes one big point up front:
When performance is lacking, everyone knows it; when performance is on par, it may not be noticed .... until it is.

KPIs for success
So, what's par for the PM? What goes into the personal track record?
Harvey looks at these as instrumental to a winning track record, stuff that will get noticed over time
  • Delivery according to expectations
  • Budget acumen
  • Process improvements
  • Relationships and communication
  • Risk management
  • Customer orientation
And for the MBAs among us
Harvey's list is all good stuff; all project oriented. If you're going for a big promotion, my advice: Add to Harvey's list your competence with the business side. A good place to start is the Balanced Scorecard -- Measures that Drive Performance. But that's another story.

(*)  Another way to express Ness' idea: Be consequential!
But consequential actions could be writing (consequential writing is an action, in spite of Ness').

Buy them at any online book retailer!

Friday, June 7, 2019

The core of knowledge

... statistics is what tells you if something is true, false, or merely anecdotal; ... it is the instrument of risk-taking
Statistical and applied probabilistic knowledge is the core of knowledge;
Nassim Taleb

You got to hand to the guy: he is passionate about his subject.

Of course, he's also the first person to tell you that his most infamous invention, the "Black Swan", is black - - that is, extraordinarily rare - - because there are no statistics to predict it.

Statistics in the PMO
Two of the more useful properties of statistics are these:
  • They are are surrogates of a past track record; thus, handy for estimating
  • They are persistent in the sense that they are survivors: wait weeks or months and if the circumstances haven't changed, neither have the statistics. Thus, your story doesn't change with time, an idea called "stationary".
Rules of thumb
For project purposes, rules of thumb may be as useful as actual statistical analysis:
  • There's shift-right bias at milestones; milestones are inherently weak objects in the schedule
  • Diversification follows the "square-root-of-N" rule: diversify into 4 independent events, and get a 2:1 improvement in risk (square root of 4 is 2)
  • "Expected value" -- which is a risk weighted average -- is usually more pessimistic, and therefore more conservative, than "most likely" value" (the single value with highest individual probability)
  • "Expected utility value" is not objective, and subject to many biases (utility is a weighting according to usefulness)
  • Independent events tend to centrally cluster--the theory of central tendency
  • A sample of a large population can be an economic approach that saves time and money

Buy them at any online book retailer!

Monday, June 3, 2019

Showing confidence

Making a presentation?
Speaking to a large group?

Are you confident?
Yes? Good show! Hopefully, your audience will think so also.

Mike Clayton has a helpful posting about behaviors during your presentation that will go along with projecting confidence to your audience. Helpfully, Clayton says it takes less than 2 minutes to read it.

Here are two ideas I like, especially the first on about hands. I've personally made that a "must do" and its proven very helpful

Keep them still. Fight the fidget. Take everything out of your pockets (if you have them) to avoid the temptation to play with them. And if there's nothing in your pocket - don't play with it.

Slow down. Nervous people hurry. With speakers I also talk about the power pause, to get and hold attention.
TED-talks: See this stuff in action. View some TED-talks and watch for the confidence projection techniques. You'll find Clayton's advice is universally practiced.

Buy them at any online book retailer!

Friday, May 31, 2019

Project Bulls**t

Many fine books have been written about 'bull' and its excrement, 'bulls**t' (*). Indeed, such may go back to at least the 17th century, if not before, as written into plays and documents of the era.

And so, is it any surprise that, four centuries on, many in the PM profession pride themselves as good bulls**t detectors, having the cultural training to recognize such that comes from a lifetime of exposure and experience?

Indeed, no less an eminence than Harry Frankfurt, a distinguished moral philosopher and professor emeritus at Princeton has been quoted (**):
"One of the most salient features of our culture is that there is so much bullshit"

Lies vs bulls**t
But here's the important matter: project success depends on trustful and trusting relationships -- no news there -- and trust, in turn, depends on a track record of truthfulness. Amen to that, to be sure.

Can the bulls**ters be trusted? Are they truthful?
And, in the same vein, what of the liar?
Distinctions without a difference?

Not the same! Not so fast!
If we can pretty well detect bulls**t, and see through to the truth, is there any real harm done?
What about lies?

Frankfurt goes on (paraphrasing):
The essence of bulls**t is that it is produced without concern for the truth. Indeed, it need not be false, even though the perpetrator is faking knowledge (a stopped clock is right at least twice a day). That is, the bulls**ter is indifferent to the truth .... could be right; could be wrong; doesn't care.

The liar, on the other hand, has a very good handle on the truth which he/she purposely tries to hide or obfuscate. Indeed, the liar is quite sensitive to the truth, not indifferent, and wants to lead us away from it.

Caring or not caring
The liar cares deeply about the truth; the bulls**ter doesn't. At the end of the day, who is the greater threat? Frankfurt would have you believe it's the bulls**ter; I'm not so sure.

The bulls**ter, once identified, can be written off to exaggeration, but not willful deceit.
The liar is willfully deceitful.

In my PMO, if I have the insight to choose, I'm going to take the bulls**ter. My idea is that perhaps there is useful person to be rescued, untainted by a willful disregard for truth.
(*) "On bullshit" by Frankfurt (2005); "On Lying" by St Augustine;  "Your call is important to us; The truth about bullshit" by Penny
(**) Essay: "Say Anything" in the book "When Einstein walked with Goedel" by Holt

Buy them at any online book retailer!

Tuesday, May 28, 2019

Mystery, secrecy, and privacy

This blog is not about politics, so we'll keep to the knitting and wax on about mystery, secrecy, and privacy in the project management domain.

For today's screed, I took a few thoughts from an unlikely source of PM advice I found in an 2013 article by Jill LePore entitled "The Prism" (a term in the news of that time)

I, for one, had not thought a lot about the subtle but substantive differences of our three title terms insofar as they have their individual effects on governance, understanding, communications, and perhaps even innovation.

By Ms LePore's reckoning, we can divine the following:

  • Mystery is knowledge held by a very few, perhaps only one -- the project's "Almighty" -- with the intent of creating a mystique around the idea or the individual. In other words, the mystical knowledge has no overt operational purpose since it is never to be revealed on acted upon. It's all about aura and mystification.

    Politicians love mystery and mystique, isolating them a bit from challenges. Autocrats love mystery too: mystique amplifies power. And, believe or not, the marketing department loves mystique -- mystique sells!
  • Secrecy is the way we compartmentalize knowledge intended to be acted upon and drive operational outcomes -- but only by a selected few actors.

    For whatever reason, secrecy can move the project forward when otherwise acting in a fishbowl with this knowledge is judged to be ineffective... some will be inhibited from full discourse; others embarrassed to show weakness or ignorance; and some will use the information against us.

    In business, secrecy often goes by the name "proprietary". In projects, to take one example -- but there are many legitimate examples -- competitive proposals are always held secretly from the competition.

    And, the flip side is that if your project is in receipt of proposals from vendors vying for your business, then you need project protocols to protect their competitive secrets.
  • Privacy is about our own stuff, our own thoughts, and our own biases that we can live with but choose not to share. Although we are social in our relationships, everyone needs their moment and place of privacy.
    (See: issues with open space project space)

    Of course, sometimes privacy crosses over into a personal secrecy to compartment things you are doing. That's where the trouble begins because governance, understanding, communications, and perhaps even innovation are surely threatened by personal secrecy just as official secrecy can have debilitating effects.
Bureaucracy begets mystery
Mystery accumulates around bureaucracy, whether intended or not. The larger the structure the more mysterious are those in the head office -- including, by the way, the PMO. Open door policies and other communications are partial anecdotes, but the real anecdote is a flat organization.

Mystery can be a tool
On the other hand, companies exploit mystery to create an aura in the marketplace and enhance their competitive posture, especially on competitive project proposals. Every proposal I ever led had a marketing guy attached whose job was not only to develop information on the competition but also to create mystery in the marketplace -- scaring the competition and attracting the prospective customer.

Secrecy requires definition
Secrecy is about deliberate compartmentalization. And "deliberate" is the operative term. To be deliberate requires definition in advance of the criteria to invoke compartmentalization. In some domains, the requirements and definition come by contract and are imposed on the project. But there's also a lot of proprietary activity -- see pharma R&D for instance -- where corporate secrecy abounds.

Privacy is a late comer
In the genealogy of these things, privacy is a late comer. As mystery became less religious and more secular as Europe exited the Dark Ages, privacy in personal affairs became more of a main stream idea. But in the United States, it did not acquire a legal definition until late in the 19th century. Now, projects have to address privacy issues left and right, and with all manner of cultural and geo considerations. And, the culture of privacy is a shifting ground, so projects are always in a demand-driven mode vis privacy requirements.

In some respects privacy is a wicked requirement: circular, no apparent point of entry, and self conflicting in many respects. No small matter as you try to contain scope, cost, and meet milestones!

Buy them at any online book retailer!

Friday, May 24, 2019

Feasibility and risk assessment guide

A posting from Matthew Squair put me onto a nice one page pdf template for requirements feasibility and risk assessment.

The chart links compliance, achievability, and technical consequences.

You could, with just a little effort, build an an interlinking matrix, something like a QFD (quality function deployment) house of quality :

One note:
If you don't recognize the shorthand scientific notation for numbers, like 1.0E-3, this is read as 1 with an Exponent of -3, meaning 1/1000, or 0.001. Similarly, 1.0E+3 is read as 1000. 

Frankly, I would ignore the number rankings. You can make up your own, or have none.

The important content is in the categories and the category definition.

Buy them at any online book retailer!

Tuesday, May 21, 2019

About that coordination thing ....

We're all supposed to coordinate. That's written somewhere in the PM literature and taught in bureaucracy school everywhere. And so I was impressed with this bit of wit(*):
"Successful coordinating mechanisms depend on mutuality. The greatest chance of success derives from mutual benefit tied to sufficiently high priority programs
Lesson learned: you haven't coordinated if the other person hasn't acknowledged AND hasn't offered something in return. The "sound of one hand clapping" and "coordination without acknowledgement" are about equivalent.
... "[beware of the] weak coordinating level of [just] interaction rather than [the stronger leverage] in budgeting and policy"
Be consequential: Well, no one wants the label of "weak coordinator", so let's all go for "strong"; to wit: let's spend our energy and influence being consequential.

"Budgeting and policy" are C-suite speak.
You, on the other hand, may be working execution rather than forming policy.
Nonetheless, even at the execution level, there may be more areas of leverage than 'money and resources' and a hammer on direction (strategy), but those are two pretty good ones.

Thus, if you're not "coordinating" in those areas, what is it you're coordinating about that is consequential?

(*)Dr. L. Parker Temple, III
Policy advisor to President Reagan

Buy them at any online book retailer!

Saturday, May 18, 2019

It's as easy as 1-2-3!

Counting, positioning, or measuring: what's in a number?

Remember pre-school or kindergarten: we all "learned our numbers".
Ah! but did we?

Want to count something? Just use the integers, starting at 0 and going in familiar step: 1, 2, 3 ....
The count takes on the dimension of what you are counting: dollars, inches, meters, liters, etc
You can do arithmetic on count, but because of the dimensioning, the results may or may not be viable: square inches are ok, but square dollars are not.

Want to rank or position something? Again, we fall back to the integers -- 1st or 2nd position is good; position 1.2 in a queue has no meaning or implementation. And, there is no dimension per se in a position.
Some arithmetic still applies, but it's tricky. Addition is not commutative:
  • You can add 1 to the first position to get the second position, 
  • But you can't add first position to a 1. Stuff like that.

Want to measure something? You can use any rational number for measurement. (a number that can be fashioned by the ratio of two numbers). Really, anything on a measurement scale is rational and can be a measurement.

But there are irrational numbers which can not be formed by a ratio (like "pi"). Nonetheless, you can measure with irrational numbers. The area and circumference of a circle are measured with "pi"

For a number to be useful in measuring, every number in between has to be meaningful. That's why you don't do measurements with ranks and positions: the in-between numbers are not meaningful.

Calibration: And, to be meaningful, the scale has to be calibrated.  A ruler with irregular spacings or a warped or bent rule, or guesses without reference to benchmarks or other reference classes are uncalibrated. And, thus, every number in between is not meaningful.

Project management
And so, where does the rubber meet the road in project management?
  • Budgets, schedules, resource estimates and utilization need calculation, measurement, and counting
  • Anything else that's quantitative

We're done here!

Buy them at any online book retailer!

Wednesday, May 15, 2019

To simplify ... or not?

Shim Marom has interesting post on complexity wherein he says this:
"A lack of an intellectual capacity to grasp a complex system is not a sufficient argument or drive for simplification.

If you artificially simplify a complex system you end up with a different system that, while simpler, is fundamentally and conceptually different from the one you started with and thus, simplification ends up with destruction."

So, what are we to do about a system we don't understand? Should we:
  • Get a smarter guy to understand it for us? Possibly; we can't all understand the particle collider
  • Design in some fail-safe stuff so that even a chaotic outcome is contained? Yes, fail-safe is always a good idea if you have the right assumptions (See: Fukushima, March, 2011)
  • Design a different system altogether -- one that we can understand? Yes, that might be a good idea (See: HAL in 2001: A Space Odyssey)
  • Do the destructive simplification Marom talks about?
A system engineer would say: "Yes" to all of the above, situationally, as required.

About destruction
I suggest that "destruction" could be the intended end-game insofar as if you can't understand a system you may not be able to control it, and certainly can't predict its behavior. So, "destruction" to a simpler device may be an important and required objective. Lord knows, we have enough stuff we don't really understand!

CAS is not for everyone:(*)
Also, when discussing complexity, especially adaptive complexity, one must be careful not to cross domains: CAS in biological and chemical systems, and others like weather systems, is not a phenomenon we have to deal with in man-designed physical systems that operate within reasonable physical limits. To impute CAS properties improperly is one of the common errors I see.
(*) Complex Adaptive Systems: the behavior of the ensemble is not predicted by the behavior of the components. They are adaptive in that the individual and collective behavior mutate and self-organize

Buy them at any online book retailer!

Sunday, May 12, 2019

The first thing you do to reduce risk ....

The first thing you do to reduce risk .... is: loosen the coupling between sources of effects. Create buffers; remove dependencies; install redundancy.
  • This is a concept from System Engineering (buffers, dampers, redundancy; but also loose tolerances; fuses; barriers and walls ... anything that inhibits propagation of effects)
  • This is a concept from scheduling (Critical Chain by Goldratt; buffers to critical path)
  • This is a concept from the Theory of Constraints (also by Goldratt; manage the coupling constraints between processes)
  • This is a concept supported by elementary statistics (shift right bias)
  • This is a concept from anti-fragile theory (by Taleb; in effect, shock absorbers)
  • This is the concept of the "normal accident" (by Perrow, aka: stuff happens! So, expect that it will)
Coupling applies to the project office
And, this coupling idea applies not only to physical systems but to organizations. (Again, Charles Perrow). Organizations are systems, after all.  One miscue in an organizational element is to be absorbed and isolated from other. In an extreme: quarantine.

Buy them at any online book retailer!

Thursday, May 9, 2019

Hub and spoke project architecture

On the HBR Blog Network, Andrew Shipilov has a eye-catching post on "hub and spoke" project networks, or alliances between project partners, as he describes them.

(Say "network" to me and I always jump first to a mind's-eye image of a "mesh", but actually that's one of several general ways to think of networks, and in most situations not a good general model for governance.)

Shipilov posits that simple hub-and-spoke arrangements in truly complex and challenging systems, with the prime contractor and an SI (system integrator) at the hub, inhibits critical interactions between the other partners, each of which is on a spoke. He attributes some project failures to this governance model.

What to replace it with? After all, hub-and-spoke is the essence of prime contractor command-and-control over the myriad partners, to say nothing of the legal details of who has privity of contract.

Shipilov recommends the "alliance network" wherein there are multi-lateral relationships for innovation, data exchange, and cooperation, not necessarily under the watchful eye of the SI (though, if the SI is on the ball, all the consequential stuff is known at the PMO)

About the alliance network, we are told there are these advantages:
"First, alliance partners are more likely to deliver on their promises.  If information flows freely among interconnected partners, how one firm treats a partner can be easily seen by other partners to whom both firms are connected. So if one firm bilks a partner, other partners will see that and will not collaborate with the bilking firm again.

Second, integrated networks facilitate fine-grained information exchanges because multiple partners have relationships where they share a common knowledge base. This shared expertise allows them to dive deep into solving complex problems related to executing or implementing a project."
Fair enough. But one caution: You can't be a control freak and sleep nights with an alliance network!

Buy them at any online book retailer!

Monday, May 6, 2019

Value stream mapping

Value stream mapping seems to be a new label on old wine. But nevertheless, the wine ages well. In the old days, we simply called it process mapping.

Value stream mapping derives from the Lean community, where of course the focus is on leaning out non-value add. So, in value stream mapping, each activity, to include the workflow of authorization and other governance, and ancillary activities, like a trouble report or a status report, is evaluated for value-add.

And, of course that begs the question: what is value-add? There is an answer, of course, but it may take a bit of customization to make it work everywhere. Simply put: anything that is ultimately delivered to the customer or makes the customer deliverable a good thing in the customer's eyes.

A lot of governance would not fit this definition directly, but most indirect activities don't. Nevertheless, most practical organizations can't live without them, so there's a certain valuable non-value overhead that goes along with everything.

One thing I do like about value stream mapping is the clarity of the diagramming. Take a look at this diagram:

If you're interested in more, this diagram came from a nice post at LeadingAnswers

Buy them at any online book retailer!

Friday, May 3, 2019

Trust and loyalty

From time to time, a profound thought strikes here at Musings. Today, it's these questions:
Is it necessary for there to be trust in order that there be loyalty?
Can there be loyalty and simultaneously mistrust?

Spoiler alert: there's no right answer. It's a matter of your values and beliefs, for which there is no proof, validation, or algorithm.

So, where did this come from?
  1. In my agile classes, we discuss the desirable (or essential?) elements of leadership in the agile environment. The word trust comes up in almost every student input.
    I don't recall 'loyalty' ever coming up (though I did search the archives), either as a quality looked for in a leader or expected to be given to a leader
  2. In the Winston Churchill biography "Churchill the Lion", the biographers -- William Manchester and Paul Reid -- describe Churchill's relationship with Josef Stalin -- from 1942 onward when the USSR allied with the U.S. and Britain in WW II -- as mistrustful but loyal. I was really struck by that assessment. (Perhaps this is the earlier version of Reagan's "trust but verify")
So, back to the questions posed above; I think this:
  •  I can be loyal to an institution (team, project, business unit, agency) without being trustful of its tactical leadership. However, if the mistrusted leadership is then strategic and becomes the strategy of the institution, then you lose me. (mistrust tactically, but verify strategically)
  • At a personal level, I can't be distrusting and loyal to a person at the same time. At a personal level, trust and loyal have to go together.
  • I think, without knowing, that WSC was loyal to the cause represented by the alliance with the USSR without being trusting of its leadership. I get it; it can work -- but only for a short time to overcome a major issue where everyone is needed on some level.

And, Mike Clayton has an excellent piece on 10 qualities of leadership -- but loyalty (given or expected) is not among them. So, another point of reference for those looking.

(Disclosure: I resigned an executive position in a large company when I could no longer trust a more senior executive and felt I could not be loyal to him, so that experience probably colors my thinking)

And, ONE MORE THING: you don't get the word 'respect' on leadership attribute lists. I wonder if trust-respect and loyalty somehow go together... could you possibly trust someone that you don't respect? Perhaps, one begets the other.

Buy them at any online book retailer!

Tuesday, April 30, 2019

Mixing Agile with oil and gas

There comes a point where more planning can not remove the remaining uncertainty, instead execution must be used to provide data and remove uncertainty.

This quote comes from a nicely argued case -- from the agile blog 'leading answers' -- for mixing agile methods in rather traditional businesses, like the oil and gas exploration/production business

If ever there was a business that benefits from Boehm's Spiral Model, OGM (oil, gas, minerals) is certainly one. (Disclosure: I hold some OGM leases in Texas, so I've a bit of personal experience with this)

So, what've got here?
  • A lot of risk acknowledged up front (can't know everything -- thus the opening quote)
  • A need to run with pilot projects before committing to production
  • A need to tie into legacy systems (in the OGM case, distribution systems)
  • A lot of deliverables that can be done incrementally and then integrated
  • Small (it's all relative re small) teams, co-located, personally committed, with risk hanging on every move.
  • A degree of local autonomy required to meet the challenges of the moment
Sounds like an environment that needs agility, if not agile methods, on a lot of the stuff.

Of course, there's "one big thing":
You can't go around self-organizing (agile speak) willy-nilly! There's regulatory constraints everywhere and safety-first doctrine hanging on every move.

So, yes, there is a big bureaucracy that watches over... it's certainly more intrusive than a coach or a servant-leader (more agile speak)  (I'm sure they never heard this stuff in an oil field or an offshore rig!). In fact, I'll bet the rig boss is a force to be reckoned with!

Buy them at any online book retailer!

Saturday, April 27, 2019

Someone says 'calculus' and you think ....

Someone says 'calculus' and you think ....
  • Yikes!
  • Get me out of here!
  • Calculus doesn't belong in the PMO
  • I took it in high school.... enough already!
Actually, some things are simpler than they appear:
  • Speedometers and direction
    You're driving. Got a smooth curve to go along (which could also be a straight line)?
    Want to find out which direction you're going at a particular point? Or, if you are changing direction? Or, how fast you're going

    "Derivative" is your answer!  (It's the most elementary calculus operation)

    The first derivative of distance with time (dx/T) is velocity (a small change in distance per a small change time); and  ...

    The first derivative distance with distance (dy/dx) is direction (a small change of distance vertically per a small change of distance horizontally.
    Zero means you a are going straight horizontally (dy = 0); infinity means you are going straight vertically (dx = 0); and any other number means you are going in a direction not either one of those)

  • Small stuff into a large thing
    Got bunch of small things -- or effects -- that need to be added, all of which are bounded by some curve (boundary)? Say, for example, the pixels in your camera or TV screen

    In effect, do you need to see the effect of a lot of small stuff co-existing, but from a distance so that each is not readily discernable? The so-called 10,000 ft view?

    "Integral" is your answer! And, taking an integral (meaning: calculate an integral) is what we call integrating or achieving integration. Integration melds all the little boundaries into something larger and more homogeneous
There you have it! Calculus 101. Not so difficult after all

Buy them at any online book retailer!

Wednesday, April 24, 2019

A paradox of motion

Can't get off the dime? Not motivated? Putting things off?

Perhaps Parmenides's clever disciple, Zeno of Elena, has the perfect proof that it's not your fault!

He wrote four paradoxes of motion.
Consider his "dichotomy paradox" which addresses the infinite divisibility of space:

"In order to complete any journey, you must first travel half the distance. But before you can do that, you must travel a quarter of the distance, and before that an eighth, and so on. In other words, you must complete an infinite number of sub-journeys in reverse order. So, you can never get started!"

Buy them at any online book retailer!

Sunday, April 21, 2019

Knowing more or less

I had thought that the magic of the information age was that it allowed us to know more, but then I realized the magic of the information age is that it allows us to know less

It provides us with external cognitive servants---silicon memory systems, collaborative online filters, consumer preference algorithms and networked knowledge. We can burden these servants and liberate ourselves
David Brooks

Buy them at any online book retailer!

Wednesday, April 17, 2019

Riding a dead horse?

The code of tribal wisdom says that when you discover you are riding a dead horse, the best strategy is to dismount. In the [project office], we often try other strategies with dead horses, including the following:
  • Buying a stronger whip;
  • Changing riders;
  • Saying things like ‘this is the way we’ve always ridden the horse;
  • Appointing a committee to study the horse;
  • Arranging a visit to other [PMOs] to see how they ride dead horses;
  • Increasing the standards to ride dead horses;
  • Declaring the horse is better, faster, cheaper dead; and finally 
  • Harnessing the dead horses together for increased speed 
Thomas Penfield Jackson

I was recently shown this by Alex Walton, principal at, a statement by U.S. District Court judge Jackson, while managing the Microsoft case in 1999. I've edited it with [ ] to apply it to project management.

I'm not sure that Jackson was a happy camper when he said this; a good deal of his ruling in the Microsoft case was reversed on appeal.

Buy them at any online book retailer!

Sunday, April 14, 2019

Stage gates and Agile?

Stage gates and Agile? To some, that might sound horrifying! Not exactly! One of my Agile Project Management students asked me about stage gates and agile. My first response was this:
  • Agile is not a gated methodology, primarily because scope is viewed as emergent, and thus the idea of pre-determined gate criteria is inconsistent with progressive elaboration and emergence.
  • Agile does embrace structured releases; you could put a criteria around a release and use it as a gate for scope to be delivered
  • Re budget: agile is effectively 'zero base' at every release, if not at every iteration. You can call the question at these points of demarcation.
  • Agile is a "best value" methodology, meaning: deliver the 'most' and 'best' that the budget will allow, wherein 'most' and 'best' is a value judgment of the customer/user.
  • Of course, every agile project should begin with a business case which morphs into a project charter.
    Thus, the epic narrative (the vision narrative) is told first in the business case, and retold in more project jargon in the charter.
    Thence, there are planning sessions to get the general scope and subordinate narratives so that an idea of best value can be formed.
But, DSDM is one agile method, among others, that is more oriented to a gated process than say, SCRUM. To see how this could work, take a look at this presentation:

And, you can follow-up with this:

Buy them at any online book retailer!

Thursday, April 11, 2019

Anti-fragile -- surviving shock

A good system is one in which the risks are visible
Nassim Nicholas Taleb

Nassim Nicholas Taleb, most famous for authoring "The Black Swan: the impact of highly improbable fragility", also has a just-as-interesting book: "Antifragile: things that gain from disorder"

Taleb's objective for this book is to be the definitive explanation of the spectrum of fragile (read: Black Swan, incalculable risk), robust (read: survivable, calculable  risk), and antifragile (read: risk driven improvement).

In a few words, his points are these:
  • Fragile systems can not absorb shock; they break, they fail, and they do great harm when they collapse
  • Robust systems can absorb shock, but robust systems are no better off after the shock than before; they don't learn or improve from the experience
  • Antifragile systems not only can absorb shock, but the disorder/disruption is actually fuel for innovation and improvement. They next shock will have less effect; any new system will build upon the disorder of the past and be better. 
Mulitple systems
And, we're not talking physical systems necessarily; all manner of human factors and biological systems are included, along with political systems, etc.

One example he has given in a television interview was comparing a taxi driver and an office worker. The former deals with the uncertainty of business every day and constantly adapts to stay afloat economically; the latter, if laid off suddenly, is devastated and adrift. The former is antifragle (because of constant learning and adaption); the latter is fragile (because shock is damaging)

In business, he says the restaurant and aviation sectors are antifragile, constantly learning from mistakes, and the financial industry is fragile -- vulnerable to black swan events.

Domain sensitivity
Taleb makes the point that the qualities of antifragile are at the same time domain dependent -- that is, context sensitive -- and domain independent -- that is, it is valid to represent the phenomenon in one domain with similar characteristics in another domain, though often we miss this cross domain connection.

Taleb wrties:

"We are all, in a way, ... handicapped, unable to recognize the same idea when it is presented in a different context. It is as if we are doomed to be deceived by the most superficial part of things, the packaging...."

Redundancy and risk management
We learn this about risk management:

"Layers of redundancy are the central risk management property of natural systems. ... Redundancy ...seems like a waste if nothing unusual happens. Except that something unusual happens— usually."

Project context
Almost every project I know of embraces continuous improvement. But to make it effective, CI should be paired with reflection, investigation of root cause, and actionable strategies. These get at the learning component of being antifragile.

Actionable strategies begin with a dolop of system engineering: decouple where possible to trap problems before they propagate. Decoupling is most often accomplished by modularity and defined interfaces.

And then we add redundancy -- equivalent capabilities implemented in different ways decoupled for independence -- and cohesion.

Cohesion is the property of absorbing shock without failure. We get at this with buffers, redundancy, and elastic physical properties.

The final test
Taleb gives us this as the final test:

[We] .. detect antifragility (and fragility) using a simple test of asymmetry: anything that has more upside than downside from random events (or certain shocks) is antifragile; the reverse is fragile.

Buy them at any online book retailer!

Monday, April 8, 2019

Risk un-management

Risk un-management?
Perhaps the largest task within risk management, and requiring the greatest judgment, is "risk un-management"

On any project there are going to be dozens, perhaps hundreds, of unmanaged risks. These comprise the population to be un-managed.

I doubt this is news to anyone, but these are, as a group, more numerous than those selected for the usual risk management paradigm. Among the un-managed:
  • Weaknesses that are Low-Low on the risk register's probability-impact matrix, maybe even all the way to High-Low (p-I)
  • Threat events or their effects that are off baseline, not in the project plan, and range from Low-Low to High-Low, perhaps even Low-High also (p-I) 

So, you've not put the unmanaged event or its effects in the project plan, but probably you have identified some of them and put them below the line of those risks that you will actively manage. Other un-managed will pop up along the way, to be thought about, but then cast aside for active management.

Four strategies, but only one applies
Among the four big strategies--accept, avoid, mitigate, and transfer--which one is being used in this management scenario?

If you picked "accept", you get the risk manager's prize for this posting. Indeed, this is 'acceptance' of risks that are below the line and not being managed.

What could possibly go wrong?
Frankly, for many, the idea that we're going to sit back and accept risk is an uncomfortable position to take. But it happens all the time. When my risk management students lament that their organization has no risk management process or strategy and just deals with risk as they come along, I respond:
"No strategy" is a strategy of sorts in the sense that you've embraced "accept" as your risk response plan. In that event, the need to actually do a lot of work up front to identify risks is really not too productive.
If the organization is risk-seeking in attitude, this may be just fine.
After all, you're just going to accept whatever comes along and deal with it.

Buy them at any online book retailer!

Friday, April 5, 2019

No points in projects!

There should be no points in projects
That is, there should be no single-point estimates -- old news to be sure, but timeless
But also there should be no single points of simultaneity, like events finishing "at the same time"

But what about "now", as in "right now on the clock"? Is "now" not often a point in the PMO schedule?

Not exactly. A somewhat startling observation is that scientists estimate that our sense of "now" is not a single point, but indeed, a duration! (*)

How long is the "now" duration you ask? Nearly forever: 3 seconds!
From the essay "Time -- The Grand Illusion" (*)

"What science can tell us something about is the psychology of time's passage. Our conscious now -- what William James dubbed the "specious present" -- is actually an interval of about three seconds

That is the span over which our brains knit up arriving sense data into a unified experience"
Bottom line: No points in projects!

(*) Chapter 1 in the book "When Einstein Walked with Godel, Excursions to the Edge of Thought" by J. Holt, 2018

Buy them at any online book retailer!

Tuesday, April 2, 2019

Executive leadership -- the big three

Want to be a leader?
Think you are a leader?
Admire someone who is a leader?

These three attributes better be in place, and obvious:
  1. Be able to recruit the right people. Recognize talent; get the talent fitted to the task, considering not only experience, but temperament and judgment; toughness and stress tolerance.
    Oh! if you make a boo-boo here, have the strength to relieve the untalented and move for a replacement!
  2. Be able to make the big decisions at the highest level of strategy: how, when, and why; where and how much.
    Be able to avoid the paralysis of analysis and have tolerance for the stress of uncertainty. And once a decision is made, leave it made.(You can't be a carpet walker reliving every decision)
  3. Be able to motivate, inspire, and marshal resources to the task. Follow me! I know where we are going, even as I need you to get us there (I'm not the tactician; I may have no competence in task execution)

Buy them at any online book retailer!

Saturday, March 30, 2019

Burn-down chart: an analogy

It seems that there is always confusion the first time someone rolls up on an agile methods burn down chart:
  • What are we burning?
  • How much is there to burn?
  • How long does it take?
  • What is the starting point?
  • When does it end?

An analogy
Think of a burn down chart in the same way you regard the fuel gauge in your car:
  • You fill up the tank
  • You drive around, consuming fuel
  • Eventually, it the fuel runs out, the gauge shows empty, and the car stops
So, to make the analogy:
  • The gauge, if it has any metric calibration at all, probably says "full" at the top.
  • Let's say that "full" is 20gal (US) or about 75ltr. So, the gauge could read 20gal instead of "full".
  • But, if the car gets 30mi/gal, then the gauge could read 600mi (965km) when "full" instead of 20gal. Some driver digital display systems give such measures
  • But, if you drive about 10mi (round trip) every time you run an errand, go shopping, go to a restaurant, etc, then the gauge could read 60 trips when "full" instead of miles or gallons. Naturally, when the gauge gets to 1/2, then you've got 30 trips left in the tank.
And so it is with a burn down chart.
  • Typically, we're burning some consumable resource, like hours (gallons of fuel), to empty the backlog (tank)
  • When the backlog runs out, we stop
  • But, we could look at some velocity, a rate of consumption, like stories per hour (miles per gallon)
  • Or, we could look at the number of stories (trips to the store) we expect to complete if we burn all the hours (fuel)

Buy them at any online book retailer!

Wednesday, March 27, 2019

Can you beat a checklist?

Can anyone image doing serious risk management without a checklist? (The answer, of course, is No ... or, it should be!) Actually, any procedural management can benefit from a checklist.

There's been whole books written about checklists. In fact, one of the more prominent books -- "The Checklist Manefesto" by Dr. A. Gawande -- entitles Chapter 1: "The Problem of Extreme Complexity", recognizing the contributors of breadth and depth and interdependencies (check on this before you do that....) are more than we can reasonably keep in mind.

PM Tool Heresy
Here's some heresy for the PM tool geeks among us: Many PM tools are great for laying out the schedule, the architecture, and for obtaining estimates -- via simulation -- of likely outcomes, but they are really burdensome at day-to-day management.

Why so? In a word, complexity.

You can't -- as a practical matter -- put all the dependencies in the tools or the logic would be byzantine.

No one could understand or follow it if you put it down (why did you do this? why did you do that?..). Some interactions are best left to the team leader.

What's a PM to do?
And, so how to manage those interactions and day-to-day requirements? Checklists! Check off on this and check off on that.... And, it's a great tool at a daily stand-up

Here's some specifics:
  • Small lists... No list too large; keep the near-future in sight
  • Lots of lists; make a new one every time the situation changes
  • Coordinated lists; I have this one.. do you have it's companion?
  • Reusable lists; once a list is validated by actual use, archive it for reuse
  • Validated lists; get SME input to validate the list... a list can be just as wrong as any other tool
  • EV lists; Don't put aside earned value... the sponsor and everyone involved wants output, and they want output commensurate with its value
  • Kanban lists; teams push things along through a sequence of steps... did everything get DONE?

Fair enough.

It's all about situational awareness, look-ahead strategies, and understanding the constituents of getting from here to there. There's no new scope; just go to the scope statement for the parts and go to the schedule for the milestones.

Then: checklists!

The end.

Buy them at any online book retailer!