The Trust-Innovation connection

---

This statement is profound; I'll let it stand on its own:

When there is trust in society, sustainable innovation happens because people feel safe and enabled to take risks and make the long-term commitments needed to innovate.

When there is trust, people are willing to share their ideas and collaborate on each other’s inventions without fear of having their creations stolen.

Thomas L. Friedman

---

Bookmark this on Delicious

Options and hedges for projects?

---

In the financial strategies domain, we hear about options and hedges all the time. But in projects?

Actually, the same ideas apply in projects, though often the words we use are different. So, take a look at this:

Options: applying this strategy, we make a small down payment now in order to have the choice (option) at some future time to do something we don't want to foreclose--or fully commit to--now. Usually the down payment is not refundable, a sunk cost as it were.

Option examples: we may want to keep certain options open in the supply chain; in resource assignments; in technology choices. So, we might put a down payment to reserve supplier capacity to be provided later; we might pay a SME for a minimum commitment with an option for more; we might fund a prototype on an untested technology, with choice to go forward

Hedges: Hedges are a bit different than options. We hedge when we buy or invest in a counter strategy to the baseline such that a risk in the hedge will offset the risk in the baseline; in the project situation, we may not care about unfavorable risks in the hedge, only the opportunity it provides for offsets. The nice thing about a hedge is that it is not necessarily a sunk cost; the hedge position may be refundable or liquifiable.


Hedge examples: if our project is multinational, then one obvious hedge is around currency and exchange rates. We might hedge on payments in dollars by accumulating offseting reserves in the offshore currency. Thus, we can pay invoices with the most advantageous currency.

In the technology business, especially software for safety critical systems, we hedge safety risks with investment in multiple independent solutions. If we can then use a combiner in a Delphi mode, we then hedge the risk of any single point failure. This strategy was used extensively in the shuttle safety critical systems.

---

Bookmark this on Delicious

What's wrong with risk management?

---

Here's one of those provocative titles you see from time to time. This one, however, is from Matthew Squair (formerly DarkMatter and now Critical Uncertainties), and so it carries a bit of cache:

All You Ever Thought You Knew About Risk is Wrong

And, so getting to the points, there are two:

• Point 1 is The St Petersburg Paradox, and
• Point 2 is the error between time-parallel and time-sequenced risks (See also: John von Neumann's et al Monte Carlo simulation)

Point 1
In a word or two, it's a matter of utility (that is, perceived value vs risk) and the extremity of risk vs affordability

The St Petersburg Paradox, first posed by 18th century mathematician Daniel Bernoulli, is that in the face of constant expected value, we can not expect gamblers (or decision makers) to be immune to the potential for catastrophe between one risk scenario and another. The fact that scenario expected values are perceived differently, even though they are not, is the bias behind the idea of utility.

Example: if your project has a 10% chance of costing the business a million dollar loss on a project failure, is that any different than a project with a 1% chance of costing the business a ten million dollar loss? Or, another project with 0.1% chance of putting the business out of business with $100M in losses? At some point, there is capitulation: enough is enough. Sponsors won't take the risk, even though the expected value is constant--($100K)--and modest and equal in all three situations.

Thus, someone makes a utility judgment, applying their perceived value (fear in this case) to an otherwise objective value and coming up STOP! Expected value, as a calculated statistic, obscures the extreme possibility that may render the project moot.

Point 2:
We've all been taught that rolling a die 100 times in sequence is statistically equal to rolling 100 die one time. This property is called ergodicity--meaning statistics are stationary with time...it doesn't matter when you do the rolling, the stats come up the same.

This idea that parallel and sequential events are statistically equivalent underlies the validity of the Monte Carlo simulation (MCS). We can do a simulation of a hundred project instances in parallel and expect the same results as if they were done in sequence; and, the average outcome will be the same in both cases.

But, what about the circumstances that afflict projects that are not time stationary: those circumstances where is does matter when in time you do the work? There's always the matter of resource availability, timing of external threats (budget authorization, regulatory changes), and perhaps even maturity model impacts if the project is long enough.

Consequently, when doing the MCS, it's a must to think about whether the circumstances are ergodic or not. If not, and if material to the outcome, then the MCS must be leavened with other reserves and perhaps major risk strategies must be invoked.

Summary
Maybe everthing you know about risk management is not quite right!

---

Bookmark this on Delicious

Let's hear it for the big guys!

---

There's a lot of buzz these days about small business, the individual entrepreneur, and the garage where it all started. More power to them!

But, what about the big guys? Is there no 'corporate garage' as it were?

Ferhan Bulca tells us there are actually a lot of advantages for innovation in the big corporation; maybe it's not an oxymoron. And, Scott Anthony tells us that, indeed, there is/can be a corporate garage, just like the one H-P and Apple emerged from.

Bulca sums it up this way: The big guys have---

1. Access to resources
Large companies have the most important resource for innovation: cash.

2. Established brand
An established brand does not make a sloppy product successful but it certainly ensures that the new product gets some much needed air time with potential customers.

3. Talent acquisition
IBM, for example, would have no difficulty attracting the top talent for new business ideas they are working on.

4. Create and maintain momentum
Large organizations can dedicate resources to new development while start-up entrepreneurs struggle with basic needs of life.

Somebody must buy into this. The boys at Strategy& tell us that globally, in 2010, corporate R&D was up 9% year over year to $550 Billion, led by electronics/IT, and healthcare. (Shocking! that these two would be the leaders)

All of this translates to projects and programs largely led by us (project and program managers), so our industry is rebounding, at least in dollars, faster than the world economy generally, and by a wide margin.

Of course, top innovators and top R&D spenders don't always correspond. In fact, according to Strategy&, only three of the top ten R&D spenders are also in the top ten for innovators. Thus, the small guys are the predominant innovators, but one always has to say: "show me the money". Many of us can't afford to starve while we innovate.

Booz puts the innovators in three categories (strategy characterization) somewhat akin to the Treacy-Wiersema model (customer intimacy, operational excellence, product leadership), though Strategy& opines that Need Seeking is the yellow brick road:

• Need Seekers,
• Market Readers and
• Technology Drivers

---

Bookmark this on Delicious

Top 5 ideas in statistics for PM's

---

I'm please to say that many thousands of PM's have viewed this slideshare

 

---

Bookmark this on Delicious

Monte Carlo: Garbage in; garbage out?

---

For many years, I've preached the benefits of the Monte Carlo simulation (MCS). For many reasons, it's superior to other analysis paradigms. In network analysis, for instance, it handles the parallel join or 'gate' as no other method will.

In fact, it's this very capability that renders the Monte Carlo superior to other risk adjusted ideas, like the PERT method in scheduling. PERT suffers from an inability to handle the 'merge bias' at gates because PERT does not handle the mathematics of multiplying distributions (required at gates); PERT only provides a means to calculate a statistic for each task.

Architecturally, gates are the weakest construct in schedules, so any failure to handle them is a show stopper in my mind

Quantitative methods schedule from John Goodpasture

But, my students ask me invariably: how can the MCS be any better than the 3-point estimates that go into it; if the 3-pointers are guesses, isnt' the whole MCS thing just a crap shoot?

And, the second thing they ask is: who's got the time to triple the estimating problem (from the most likely single point estimate to the trio of optimistic, pessimistic, and most likely) especially in a network of many hundreds, if not thousands, of tasks?

My answer is this: it depends; it depends on whether or not your are the work package leader concerned for a handful of tasks, or the project manager concerned for a network of hundreds (thousands in some cases) of tasks.

If the former, then you should not guess; you should take the time to consider each estimate, based on benchmarks, so that each estimate is has some auditable calibration to the benchmark.

But if the latter, then let the Central Limit Theorem do the work. A few bad estimates, indeed a lot more than a few in most cases, have negligle impact on the MCS results. In other words, the good, the bad, and the ugly tend to cluster around a central value--a phenomenon called central tendency. Thus, at the PM level, you can live without completely solid calibration. Only a few estimates need to be pretty well thought out vis a vis the O,P,ML triplett.

This may sound like heresey to the calibration crowd, but as a politician recently said: arithmetic! Actually, calculus is the better word, since we have to deal with functions. And it's calculus that gives us the tools to understand that a few bad estimates, even really bad estimates, are largely discounted for effect by the integrated effects of all the other estimates. So, let's not get uptight about a few bad eggs!

Nevertheless, to do a MCS, you do need estimates of O, P, and ML. Where do they come from?  All the tools allow for defaulting in a trio to every task. Is that a good idea?

Here's my counsel:

• Take the time to estimate the most likely critical path. The MCS tool will identify other near-critical paths, and may even find an alternate path that is critical (not the one you thought)
• Establish, in the risk management plan, a policy about the defaults values (for % of ML)
  The policy may have several elements: hardware, software, administration, and process tasks. Each of these will have hard, medium, and easy tasks.
  The policy can be a matrix of O, ML, and P defaults for each (Example: for hard software, the policy is to estimate O = 80% ML and P = 200% ML).
  These generally come from experience, and that means from actual results elsewhere, so the defaults are not just picking values out of thin air....there's usually back-up

---

Bookmark this on Delicious

Who said 'average'?

---

'Average' seems like such a common word, until you dig into it, and then it gets complicated.

Really? Isn't as simple as: add up everything (or, a lot of things) and divide by the number of things? Like, for instance, the average roll of one die:

 

(1+2+3+4+5+6)/6 = 3.5

Ooops! That's one of the problems with averages--they are often not physically realizable. No matter, the math guys are happy, even if the gamblers aren't.

That's ok as far as it goes: that's the first average we all learn. It's the arithmetic average. And, there's something subtle built in: "divide by the number of things" actually is a weighting, an equal weighting, of every thing in the summation, whether or not that a good and logical thing to do.

We could do it another way: we could look at the frequency of all those things and take the most frequently occuring thing as the average thing we would expect. Like the outcome of a pair of die:

 

1,1,7,5,7,3,7,11,7,12,3

 

Let's call the average 7 since it seems to be the most frequent, thus the most likely, so why not the average? Well, in the case of two die, it works out fine, but often the 'most likely' is either too pessimistic or too optimistic. Afterall, by using that value, we're ignoring all the information, other than frequency, that's in the value set. So, why throw away information that's sitting right in front of us?

Expected value
Maybe we should take a page out of both books and add up all the values--like in the arithmetic case--but use the frequency information to our advantage--like in the 'most likely' case. In that event,

1,1,7,5,7,3,7,11,7,12,3 becomes something like (we know that there are two 1's, and four 7's, etc)

 

1(2/11) + 7(4/11) + 3(2/11) +11(1/11) + 12(1/11) = 5.8

 

 

Now, if we get 11 more numbers from the same 'generator' that gave us these first 11, what would we expect? With no other information to the contrary, we would expect the same distribution of values

 

And, thus we've gotten around to expected value as a form of average: It's the frequency (or probability) weighted average of all the possible outcomes.

 

And, equally important, we see that 'most likely' and expected value are not the same thing functionally and are often different values as well.  Expected value uses all the information available and 'most likely' does not.

Biases
Of course, there's no silver bullet: any calculated statistic obscures the extremes; and the extremes arre where the cognitive biases lurk. Thus, we get the ideas of utility (aka, St Petersburg Paradox, and expected utility value, EUV) and prospect theory. 

Nevertheless, if you were asked to bet on one and only one outcome, you might well bet on most likely since is the most frequently occuring outcome.

Sample Average
But, here's the tricky part: what if, in the above example, we didn't know if the population was eleven numbers or eleven hundred numbers? In that event, we've got the sample average with our set of eleven numbers. Now, the issue here is this: the sample average, unlike the others discussed, is itself a risky number--call it a random number--that itself has a distribution. Afterall, if we were to select another eleven from the population, we might get a few that were different: thus, a different value for the sample average. So, we may feel compelled to average the sample averages. Good! Now that is a deterministic number if we say there are going to be no more samples.

Geometric average



And then, just as all this is sinking in, along comes the geometric average:

Geometric average is the 'n'th root of the product of 'n' elements

Sqrt (4*3) = 3.46

What's a project application of something like this? Actually, getting figure of merit between two disparate measures is a good example. Supposing we have a vendor under consideration who we've rated on a quality scale from 1 to 5 as a 3, and on a financial responsibility scale from 1 to 100 as a 75. Since the scales are different, we don't want one scale to overwhelm the other. So, we use a nondimensional figure of merit. A figure of merit would be the geo average of the scores:

Sqrt (3*75) = 15

Now, we have another vendor with a 5, 50 score. Their figure of merit is: Sqrt (5*50) = 15.8

On the basis of the FoM, the two scores are pretty close, so each vendor should be in the mix, in spite of bias, perhaps, one way or the other because of either the quality or financial performance forecast.

Oh, and did you read "The flaw of averages"? If not, it's worth some time.

---

Bookmark this on Delicious