Everyone talks about strategy, means of achievement, vision, narrative, "begin with the end in mind", even [gasp!] goals. How come this quote, courtesy of "hearding cats", still rings true?
“One of the most dangerous forms of human error is forgetting what one is trying to achieve.” – Paul Nitze (1907–2006), SecDef 1967–1969
Part of the answer, of course, is the popularity of "evolving needs" driven by the operating customer/user. To wit: whatever happened to "the stake in the ground", aka: baseline?
The good news: you could evolve into something quite useful
The bad news: you might not recognize what you've evolved to
Question: is evolution of the end-game just that: evolution; or is "flip flopping"? I suppose it depends on how black and white is the evolution.
Everyone has their own idea of leadership
Consequently, there's no one idea that is all encompassing
There is no "master definition", though you can certainly look it up in the dictionary.
Here's one that struck me as capturing the "soft power" of leadership:
"A leader’s authority comes from the [constituents'] belief in his [or her] right and ability to rule, in the willingness of individuals to suspend their own judgment and accept their leader’s because they trust him [or her] and the system he [or she] represents"
Machiavelli had explained—that “the reformer has enemies in all those who profit by the old order, and only lukewarm defenders in all those who would profit by the new order … [those]who do not truly believe in anything new until they have had actual experience of it
Quoted by Doris Kearns Goodwin, Historian
I've described what Machiavelli has said -- in past posts -- as: "Any ankle biter can say no; it takes a committed leader to say yes, and make it stick!"
So, apart from the scourge of the ankle biters, what does Machiavelli portend for the project office? Or, for the team leader, or even a team member, who wants to "change the process"?
Answer: lots of resistance from the "old order"; few climbing out on the limb with you as the "new order"
Indeed, what if the "process change" is to do away with the need for the process?
Who's not heard this one (*)?
Instead of investing to make the trains run on time, why not do away with the trains?"
(*) I admit that this one itself may be dated as trains are making a comeback, sort of. So, let's bring it up to date:
Instead of investing to make vehicle drivers better at driving, why not do away with drivers?
So, now you're in the project office inventing the "computer science" of driving decisions, such as the sundry moral questions of who to save in an accident situation: you, or the person your car is going to injure?
Your office is now the "reformer" Machiavelli spoke about: lots of enemies, as in the hundreds of thousands of professional truck and taxi drivers (to say nothing of Uber and Lyft) you will put on the bread line ... talk about enemies!!
Good luck with that
Let me know how it works for you
Making it simple for the user/customer/beneficiary often requires a lot of 'backstage' complexity. Ask any system engineer.
Project managers beware! Often, the sponsor's vision is simplicity itself. And, the sponsor makes resource commitments on their idea of value. But the sponsor's value allocation of resources may not comport with the resource allocation needed to make project outputs simple for the user, customer, or beneficiary.
Why should it? PM's can't assume the sponsor has any real idea of how to make the vision a reality. That's for the project team to discern.
Inevitably, there's going to be a gap: a gap between a value allocation on the one hand and a implementation estimate on the other hand. What bridges the gap? RISK! And of course, it's left to the project manager to the be chief risk manager.
Don't expect much help from the sponsor to close the gap. Just the opposite: expect demands that you close the gap!
I've expounded on this idea before. I call it the 'project balance sheet': a way to represent the three variables that inform every project charter: sponsor value expectation, project implementation need, and the risk between them.
The tension of simplicity and complexity is ultimately a tension between value and resources. Beware simplicity!
In an explanation of how agile fights information opaqueness, Mike presented a slide with a bar chart of team velocities and announced a 'confidence interval' as the main take away.
Gasp!.... I was shocked! shocked! to hear statistics in an agile discussion; sounds so much like management--project management at that. But, it's easy to tell that Mike is pragmatic, and confidence intervals are nothing if not practical.
Fair enough .... but actually there was no explanation given as to what entails a confidence interval. I'll correct that failing here.
First, an interval of what?
Would you believe the possible value of a random variable?
And which would that be? Answer: the sample average of velocity, call it V-bar.
And V-bar being a random variable, it has a distribution that prescribes how likely is any particular value of V-bar to fall into the interval of interest, ie, the confidence interval.
Second, we don't actually know the distribution of V-bar and we don't know the distribution of the population V (velocities), so we can't know what the next V is going to be, or its likelihood.
But, we know (from V-bar) an estimate of the population (V) mean. Thus, we can use V-bar as an estimating parameter of velocity, even though V-bar does not predict the next velocity value. (Example: average team throughput = V-bar x input units, like story points or ideal days)
Third, since we don't know, and it's not economic to find out what the distribution of V-bar really is, it's customary to model it with a distribution that has been tried and proven for this purpose--the T distribution.
The T-distribution is somewhat like a bell shaped distribution, except T usually has fat tails for small values of the parameter N-1 where N is the count of the values in the sample.
So what are the chances for V-bar, and how do you figure that out from the data given in Mike's chart?
I've reproduced my version of Mike's chart below; there are 9 velocity metrics ranging from about 37 to 25:
To calculate the quality of the confidence interval, some iteration is required. It's typical to first pick a level of confidence, say 95%, and then by use of a formula, and a set of 't' tables from the T distribution, calculate the corresponding interval. If the results are not satisfying, a new pick of parameters may be required.
Here are the steps:
Calculate the sample average V-bar, in this case 33, and the sample standard deviation, 4.1. Formulas in Excel will give you these figures from the 9 velocity points in the chart above.
Look up the 't' value in a T-distribution table for N-1. N in this case is 9.
Pick out the 't' value for 95% confidence [in t tables, it customary to look up a parameter labeled alpha; for 95% confidence, alpha = 0.05], in this case: 2.36 [there are formulas in Excel for this also]
You'll get something like this:
Calculate the interval around the center point of V-bar:
+/- t * sample standard deviation / sqrt(N)
+/- 2.31 * 4.1 / sqrt(9)
+/- 3.2
With just a little inspection of the formula above, and the t-tables, you'll discover that the interval gets wider as alpha is picked to be smaller [higher confidence]. In the limit, to have 100% confidence in the interval, the interval would have to very wide to cover every possible case conceivable.
Values in the velocity chart outside the interval are outside the quality limits of 95% confidence.
For reference, here's the model of V-bar, specifically the T distribution with N-1 = 8:
Process Improvement: Instead of trying to make the trains run on time, it might be better to do away with the trains!
Anonymous
Get it right the first time: There is no undo button for our oceans of time.
Tom Pike
Think ahead: Somebody's sitting in the shade today because someone planted a tree a long time ago
Warren Buffett
The certainty of the future: There are no facts about the future
David Hulett
Return on value: Value increases when the satisfaction of the customer augments and the expenditure of resources diminshes
Robert Tassinari
It's the customer! If the customer is not satisfied, he may not want to pay for our efforts. If the customer is not successful, he may not be able to pay. If he is not more successful than he already was, why should he pay?
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.
Pushing risk off to high-risk underwriters--most famously Lloyds of London--has been a traditional mitigation.
But for some projects and some circumstances, insurance is not practical.
There are a couple of principles that guide action.
--- 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.
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!
At school, "learn to learn". See instruction about how to ask questions; to think critically; to approach new things or even unknown things; to collaborate
Where possible, practice creativity, even if you yourself don't think of yourself as creative.
Be curious; avoid lazy practices of not seeking solutions and answers
And, then of course, there's this advice: consistently work on your personal knowledge base; it's part of your job description. Some leaders famously don't read, but among millions there are very few non-readers who are successful.
On-line is good, youtube or the KhanAcademy.com are great, but so is your local university library. Most are chock full of professional stuff -- books, papers, periodicals, videos
In other words: a high degree of self-direction and discipline are needed to maintain and impove skills. In the spectrum of situational leadership, you yourself need to be your own S1
And then there's this: if you're still looking for a job, the new resume may be a video to show how you actually work; solve problems, etc
Sometimes we lose sight of individuals in the never ending grasp for the big picture. So, it is nice to be able to thank Peter H. for his compliment. So often, the annual statement from the publisher is "lifeless" -- though the check is nice.
I read your book Project Management the Agile Way : Making it Work in the Enterprise. It is great.
Peter H.
Project Manager in retail，store and payment system implementation.
Shanghai Suburb, China
And, did I mention the book is out in a second edition. Same title -- almost. The publisher added "second edition" to the subtitle.
To all the other many readers, thanks for making the book a success!
