Sunday, February 16, 2020

Are there dead horses in the PMO?



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

Thomas P. Jackson was the U.S. District Court judge 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!

Thursday, February 13, 2020

What say: Architecture?



So, we occasionally get silliness from serious people:

" ......  many enterprise architects spend a great deal of their time creating blueprints and plans based on frameworks.  The problem is,  this activity rarely leads to anything of genuine business value because blueprints or plans are necessarily:

Incomplete – they are high-level abstractions that omit messy, ground-level details. Put another way, they are maps that should not be confused with the territory.

Static – they are based on snapshots of an organization and its IT infrastructure at a point in time.

Even roadmaps that are intended to describe how organisations’ processes and technologies will evolve in time are, in reality, extrapolations from information available at a point in time.
The straightforward way to address this is to shun big architectures upfront and embrace an iterative and incremental approach instead"


That passage is dubious, as any real architect knows, though not all wrong, to be sure:
  • Yes, frameworks are often more distraction than value-add; personally, I don't go for them
  • Yes, if your blueprints are pointing to something of no business value, then if that is really true, change them or start over... simple common sense ... but let it said: you can describe business value on a blueprint!
  • No, high level abstractions actually are often quite useful, starting with the narrative or epoch story or vision, all of which are forms of architecture, all of which are useful and informative. It's called getting a view of the forest before examining trees.
  • Yes, abstractions hide detail, but so what? The white box detail can be added later
  • Yes, roadmaps obsolesce. Yes, they have to be kept up to date; yes, sometimes you start on the road to nowhere. So what? If it doesn't work, change it. 
I think the agile principle "... the best architecture emerges ..." which is silliness writ large is the influence. We should put that aside, permanently. Why: because many small scale architectures simply don't scale.

Take, as just one example a physical story board or a Kanban board of sticky notes in a room somewhere. That architecture works well for a half dozen people. Now, try to scale that for half a thousand... it really doesn't scale. The technology doesn't scale.. you need an electronic database to support 500 people; the idea of all independent stories doesn't scale unless you add structure, communications, protocols, etc, all of which are missing or unneeded at small scale.

To the rescue: Here's another recent passage from another serious person who has a better grip:

One conjecture we arrived at is that architects  typically work on three distinct but interdependent structures:

  1. The Architecture (A) of the system under design, development, or refinement, what we have called the traditional system or software architecture.
  2. The Structure (S) of the organization: teams, partners, subcontractors, and others.
  3. The Production infrastructure (P) used to develop and deploy the system, especially important in contexts where the development and operations are combined and the system is deployed more or less continuously.




Buy them at any online book retailer!

Monday, February 10, 2020

Some risks aren't manageable




Ideas about extreme risk management have been around a long time.  No news there, so let's press on.

Here's a working definition: Extreme risks are those for which the consequences are nearly irreversible, and the impact is near-catastrophic. And, fortunately, in most cases, the likelihood of the event is low.

Because the expected value is nearly zero, but the threat so high, people are willing to pay high premiums to make the problem go away.

Thus is born the high risk insurance industry -- high premiums for low expected value! As long as the frequency of events is small, you pay and pay and they haul it to the bank.

But for some projects and some circumstances, insurance is not practical.

There are a couple of principles that guide action.

First principle, and probably the oldest is something called the Precautionary Principle.
In a few words what it means is that burden of proof about consequences is shifted to the advocate of taking action to do something (like: there's a risk; buy insurance), and away from the pessimist who is blocking the action (like: insurance is too expensive, let's risk it, or: it'll never happen).

Failure is not an option
One project example is the decision in Houston regarding the return of Apollo 13 after the explosion that damaged the spacecraft. Gene Kranz, lead Flight Director, essentially turned back the advocates for a quick return and directed an orbit around the moon for the return.

The consequences of an early return, if not successful, were fatal since the moon lander lifeboat had to be abandoned if the early return option was selected.

A good description of the decision making process is found in Kranz's book: "Failure is not an option"


1% Doctrine
A second principal is the so-called 1% Doctrine. Tom Friedman, writing in the New York Times, described the One Percent Doctrine, a phrase made famous by Ron Suskind in his book of the same title. It described the precautionary principle this way:
(advocate) If there is even 1% chance of a horrific event happening, then consider it's expected value as a certainty. 

A certainty? How does that compute?  Math: nearly 0  x nearly Very Large = nearly 1. Ergo: if the outcome is so horrific, you have to do something, even if the likelihood is very low.

Caution: such logic can lead to many unbudgeted and unexpected consequences!




Buy them at any online book retailer!

Friday, February 7, 2020

Uncertainty is a certainty



"Uncertainty is an essential and nonnegotiable part of a forecast. .... sometimes an honest and accurate expression of the uncertainty is what has the potential to save [big things].... However, there is another reason to quantify the uncertainty carefully and explicitly. It is essential to scientific progress, especially under Bayes’s theorem."
"The Signal and the Noise: Why So Many Predictions Fail-but Some Don't" 
by Nate Silver
Now, some say: "we don't estimate; we don't forecast".
Of course, that's nonsense. Everyone estimates, if even only in their head
  • How long will it take me to write this blog?
  • How long will it take me to go to lunch?
  • How long will it take me to do almost anything I can think of? 
But, Mr Silver leads all discussion of uncertainty, estimates, and forecasts around to Bayes Theorem, which can be laid out this way as a process:
  • Formulate an issue or question or hypothesis
  • Make an early guess as to outcome
  • Experiment to gather evidence as to whether or not the guess is reasonable
  • Re-formulate based on evidence -- or lack thereof
  • Repeat as necessary 
In fact, in another part of Silver's book, he says this -- a cautionary statement for project managers:
"In science, one rarely sees all the data point toward one precise conclusion. Real data is noisy—even if the theory is perfect, the strength of the signal will vary. And under Bayes’s theorem, no theory is perfect. Rather, it is a work in progress, always subject to further refinement and testing. This is what scientific skepticism is all about."
And, one last caution from author Silver -- which reinforces the ideas of the Bayes process and also makes the point -- often ignored or overlooked --  that there is often little enough data inside one-time projects to support textbook statistical approaches:
"As we have learned throughout this book, purely statistical approaches toward forecasting are ineffective at best when there is not a sufficient sample of data to work with." 


Buy them at any online book retailer!

Tuesday, February 4, 2020

Qualities you might like



Jeff Haden at the Owner's Manual on Inc.com has written about employee qualities

By Haden's telling, great employees have these qualities:
  • They ignore job descriptions. .
  • They’re eccentric...
  • But they know when to dial it back.
  • They publicly praise...
  • And they privately complain.
  • They speak when others won’t.
  • They like to prove others wrong.
  • They’re always fiddling.
I like the fiddling thing. This means curiosity. And, it could mean a propensity for innovation. If companies play into this, they'll give the fiddlers some space and time. Somewhat like Google's "20% of your time to do anything" policy.

I have managed units that had eccentric people. I'm careful to say I didn't manage people, and certainly not an eccentric. As oft said: "things are managed; people are led". In fact, eccentrics are to be tolerated at least, and nurtured at best. You never know what will turn up.

As a case in point, take a look at the famous Bell Labs where the transistor was invented and Claude Shannon discovered the limits of bandwidth. Talk about eccentrics! Like shooting fish in a barrel



Buy them at any online book retailer!

Saturday, February 1, 2020

Not a process person


Every project has them:
Some people are just not "process persons". They never do the same thing twice the same way
But more importantly: It would never occur to them to do the same thing twice the same way.
And, given a problem, they don't seek process; and really don't see why improvisation is not just as effective.
And, you couldn't label them "lean" either."Lean" requires process and tooling to minimize redundancy and non-value repetitions.

Nimble and opportunistic
If not process oriented, nonetheless these folks can be very opportunistic, grabbing onto a situation and solving it their way. Nimble, to be sure.

And, what's wrong with nimble and opportunistic?
Perhaps nothing the first time through.

Qualities you might value
But reducing whatever you are doing to its most effective process adds reliability, predictability, and portability---the ability to make the process work with others and other situations.
And, I might add: fairness---all is treated the same way, insofar as any process can be bias free

Frustrations
Did I mention that it's really hard to put together a team of non-process people? In the first place, teamwork brings a certain process orientation with it. And, in the second place, values don't align well.
"Getting it done" collides with reliability, predictability, portability, and fairness
Beware collisions!

The worst thing
The worst thing is when the team leader is not a process person; their disdain or disregard or insensitivity to process undercuts all else, leaving the "process people" with uncertain support or value-add. Bummer! 




Buy them at any online book retailer!