Glen Alleman posted this slideshare last month, and I could not do less than repeat his post
Saturday, October 13, 2012
Thursday, October 11, 2012
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.
Tuesday, October 9, 2012
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
Sunday, October 7, 2012
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!
Friday, October 5, 2012
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
Wednesday, October 3, 2012
Top 5 ideas in statistics for PM's
Monday, October 1, 2012
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
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
Subscribe to:
Posts (Atom)