Influencers and discriminating factors

---

When it's OPM -- other people's money -- the client gets to make the priority judgments.
I call them "influencers and discriminators"

Influencer	Commentary
Resources	Money, staff, infrastructure, intellectual property or access Real, virtual, remote, dedicated or shared
Time	Calendar, duration, milestones, value-add points
Scope	Client deliverables; business deliverables; project debris Agile CUD: create, update, delete agility
Quality	Fitness to use; fitness to standards; fitness to “best value”
Risk	Risk to the client; risk to the business. Impact and likelihood. Black swan effects Anti-fragile

So, here's how this looks at the extremes:

Or, maybe it's cost management

---

Buy them at any online book retailer!

Management factors for success

---

At "herding cats" there a good list of control elements in a posting I read, interesting enough that I offer the short version here:

1. Short term feedback - what's happening right in front of me? What do I need to do NOW to maintain stability, to survive for the next 10 feet on the trail 
2. Long term feedback - I see things coming ...[project managers are paid the big bucks to see around corners!]
3. Corrective actions - what corrective actions am I capable of performing?
4. Alternative choices - ... choices present themselves. Some are optional, some are mandatory alternatives.
5. Estimate what's right in front of you - A quick estimate is needed to decide what to do. Keep going, speed up, slow down, stop? All depends on the situation.
6. Estimates of needed for solutions coming up the trail - with short term estimating there are a limited number of choices, .... For longer term choices, there are more options. A  Plan B is needed as part of the normal process
7. Estimates of needed resources - The resource plan for the project is needed no matter the method used to develop the project.What skills, how many of those skills, the availability of those skills?
8. Estimates to complete -
   • On projects knowing something about when you plan to finish is part of managing the project.
   • Anyone working on a project that doesn't have some type of deadline is working on a de minimis project - it's too small for anyone to care about.
   • Same for the budget; Same for the needed technical performance
9. A Plan B and even a Plan C - planning in depth is a good idea whenever ....
   • Knowing the Value at Risk defines the magnitude and detail of the plan.
   • Risk Management is How Adults Manage Projects Tim Lister should never be forgotten
10. Knowledge of capacity for work - how big is it?
    • On projects, if we don't our capacity for work, we can't make informed estimates if we can get to the end in one piece.

---

Buy them at any online book retailer!

Transactional or also relational?

---

Here I am again: flogging my book*, with this question of the day:

Transactional or Relational? Is a project only a business transaction -- exchange one set of assets on the balance sheet (cash) for another set (project deliverables, aka inventory)?

Or, can a project also be relational -- form a partnership with the business and deliver the best value as judged by business impact?

Partnership?
Who among us would argue against partnership?
Well, actually many would.
You can only have partnership if you have shared reward for shared risk.

How is this sharing to be done with a project underway and chartered? 
The very word "sharing" dilutes control -- if not power -- shifting a bit from the project charter back to the business.
But, of course, the business has put up the money -- they've certainly got skin in the game -- so naturally the business believes they are owed the benefits of partnership.

What's a relationship?
But about relationships: we're talking about reciprocity and flows: reciprocal trust, respect, loyalty, and commitment to shared values and outcomes; flows of ideas back and forth; and flows of risks back and forth.

Are these qualities measurable? Are they manageable? (Are those even important questions to ask?) And, even if they are not the questions to ask, shouldn't we still care about them day to day in project life?

Joining transactional and relational
Let's grant for the moment that we see the benefit of joining project transactions with business relationships. What do we get?

Among other things we get access to business thinking that may inform project decisions day to day. That's important because it's actionable and ultimately will be reflected in the transactional side (measurable, manageable).

And the business may get our attention on mitigating a business risk by making some decision, some choice, some investment that we might not otherwise. Relations can point to branding, qualities of esteem, and other appeal attributes that would fall into the best value bucket and be beyond a simple business transaction.

Is this agile writ large?
Some might say I've just spent a page explaining the reason Agile is agile: the relationship with the business. In that respect, yes I agree. (And, here's a shock -- I wrote that book also!)

*If you've read the book (and liked it), please review it where other's can read about it.

---

Buy them at any online book retailer!

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!

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!

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!

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!

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!

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!