Risk ROI

Everyone will say risk management is valuable, but many [most] object to any direct costs for the process. Why so? Uncertain ROI.

This posting doesn't have the silver bullet. I'm sure you're shocked!

Nevertheless, a posting by Norman Marks entitled "Explaining the value off risk management" caught my eye.  Marks is a business commentator, so not really a member of our community.  He listed six arguments in favor of risk management, after first making this statement:

"Some people justify risk management by explaining how it protects value. That doesn’t work for me: it is true, but unlikely to open the wallet. I think you have to talk about how risk management helps the organization excel."

Fair enough.

 Among his six, I found three persuasive:

• Risk management enables better decisions, from setting corporate strategy, to driving major projects, to operational decision-making. With reliable, timely, and current information on risk (both the negative and positive potential) people can make better quality decisions
• This enables more risk-intelligent management, which can lead to optimized and sustained performance
• By anticipating potential events, the organization becomes more agile. It is able to respond quickly, whether to minimize the impact of adverse events or to seize opportunities for gain

In Marks' posting you'll find links to other related material. Among the recommendations you'll find there is admonition to not stovepipe risk management.

I couldn't agree more! It's a way of thinking and acting. Deming said: Plan, Do, Check, Act. In every element of this cycle, particularly 'check' and 'act', consideration for risk is part of the calculus.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Quotation -- the value of statistics

Statistical and applied probabilistic knowledge is the core of knowledge; statistics is what tells you if something is true, false, or merely anecdotal; it is the "logic of science"; it is the instrument of risk-taking

Nassim Taleb

 Bookmark this on Delicious  

Planning for creativity

Our local coffee shop is great for testing ideas. In a conversation with a colleague, Alex Walton of 3PM,LLC, we pushed around the idea of how to plan for creativity.

My first thought: you can't.

My second thought: well, take a page from Barry Boehm's spiral method and a page from agile, and mash them together with an implementation plan, and maybe there's something to be done.

There is a natural tension to be addressed: the creative mind wants no boundaries; the management mind wants order and predictability.

From agile: take a white board and a dart, and begin storyboarding or other creative activity.

From spiral: from the starting point, build outward in cycles, addressing a new point with each cycle with an objective of getting the right pointing vector for the implementation phase.

Back to agile: box the available resources so that something useful is more or less a certainty. After the whiteboarding and spiraling about--so called iteration 0 where no operational deliverable emerges--use one of the boxes to plan out the mechanics of implementation. It's expected that you'll begin with 10lbs to go into a 5lb box, but after creative iteration, you'll come up with 5lbs that is useful and worth doing.

Then: do it!

Then: DONE [when you have a deliverable that is useful and operational]

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Dr Management

I was given a tip to look at Dr Management, PhD, a blog link aggregator site on business and management blogs. I am impressed.

If you navigate around a bit, you come to "Top 50 blogs by business professors". The good thing is that this is not just a list of 50 links. Instead, the links are organized by major topic, and there is a explanatory headline for each.

Now, ordinarily, I gravitate to less academic blogs, but nonetheless, there are a group of blogs on technology in business, and another grouping that addresses leadership, both ideas I follow closely.

One interesting one in the technology category is Tom Davenport's site where you find topics like: "25 Years After Challenger, has NASA's judgment improved?"

And, in the leadership area: Jeffery D. Ford's blog is a great read. Example: "Does anyone really believe that a jerk of a leader can successfully engage people in a change if she simply follows the right steps?"

So, 50 links!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Planning and improvisation

At "Eight to Late" there is a recent posting on the planning paradigm contrasted with improvisation.  In the blog, reference is made to an underlying paper of some 13 years ago that discusses the reasons that business process reengineering had its heyday and demise.  Even dated, the paper by C.U. Ciborra has some really good points for project managers. 

The agile guys will love "Eight to Late's" take on planning v improvisation.  First a quote from Ciborra:

Procedural planning anticipates moves and events as if already occurred and just translated on the other side of the “now”. That is, procedural planning arranges in front of the actor the past (actions thought of as accomplished and embedded into plans), so that in performing an action he/she can encounter “in the now” mileposts which prompt the actor to do the next move… 

But then we are told:

Since improvisation occurs on the spur of the moment, what is important is the cutting edge of time, the instant of action. In this sense, improvisation lies “outside of time.” However, this does not mean that the past does not matter. On the contrary, improvisers draw upon past experiences, possibly even more than planners do. However, they do so in ways that they are not consciously aware of before the moment of action.

Sound agile, emergent, and current? Sounds like it to me. The main theme of Ciborra's paper is that improvisation is in the human spirit and instinct; any formality aimed at removing it and replacing it with a planning paradigm that is only the future played as the past-present is doomed to fail. Remedies such as risk management are insufficient or inappropriate to suppress improvisation. Indeed, it's improvisation that is needed to deal with the unanticipated.

So, as in all things, it's a matter of balance. Projects are not jazz sessons or improv events; a modicum of planning is needed and required--in mission critical projects, more than a modicum is required. But projects are not production operations either, so rather suppress and defeat improvisation, embrace the possibilty!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Of physics and biology

John Baez writes about complex systems like biological systems and physical systems such as climate and similar. In a recent post, he had a blurb about one of my favorite topics: the use of statistics in projects.

Now I've always contended that statistics is just a way of abstracting a lot of data into a few values that project managers, process designers, and systems people can use to estimate resources, evaluate risks, and forecast outcomes--all important tasks to be sure. 

So, no apologies for using such a tool to reduce the information overload in projects.

But to tell you the truth, I've not done anything with biological or pharmaceutical projects, or climate for that matter.  After reading the excerpt below, I would enter only cautiously!

Physicists love to think about systems that take only a little information to describe. So when they get a system that takes a lot of information to describe, they use a trick called 'statistical mechanics', where you try to ignore most of this information and focus on a few especially important variables.

For example, if you hand a physicist a box of gas, they'll try to avoid thinking about the state of each atom, and instead focus on a few macroscopic quantities like the volume and total energy. Ironically, the mathematical concept of information arose first here—although they didn't call it information back then; they called it 'entropy'.

The entropy of a box of gas is precisely the amount of information you've decided to forget when you play this trick of focusing on the macroscopic variables. Amazingly, remembering just this—the sheer amount of information you've forgotten—can be extremely useful... at least for the systems physicists like best.

But biological systems are different. They store lots of information (for example in DNA), transmit lots of information (for example in the form of biochemical signals), and collect a lot of information from their environment. And this information isn't uninteresting 'noise', like the positions of atoms in a gas. The details really matter. Thus, we need to keep track of lots of information to have a chance of understanding any particular biological system.

So, part of doing biology is developing new ways to think about physical systems that contain lots of relevant information. This is why physicists consider biology 'messy'. It's also why biology and computers go hand in hand in the subject called 'bioinformatics'. There's no avoiding this: in fact, it will probably force us to automate the scientific method!

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Safety risk management

Safety engineering and project management of safety oriented projects is somewhat of a world onto itself; the issues at stake are often profound.

Matthew Squair writes eloquently on this subject at his blog "Dark Matter". I found one of his papers, "Current theory and practice of risk safety management", to be a good primer to the subject.

Here's his idea of the theory of safety:

Put this in a risk management context, and you get something like this:

Squair offers several 'take away' conclusions and suggestions, but I like this one:

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

System engineering and agile

Somebody asked me the other day about the intersection of system engineering and agile. In effect they asked: what are the common elements between them?

 

My list is pretty straightforward, and more or less follows the well know V-model of system engineering:

 

We can more or less go down the list:

• Use cases support the concept of operations, and to some extent, use cases can support architecture development. Architecture, unfortunately, is not specifically represented in most agile methodologies, but it's there, even if not acknowledged.
• Dynamic backlog is the agile practice for managing requirements
• Sprints and iterations is where detailed design occurs, starting with user stories on a card wall and working through test scripts and other design support tools
• Another agile weakness is inattention to system integration and technical verfication of function and performance--a weakness largely due to the small bore focus that drove the original agile thinking.  My advocacy is that functional test scripts, written at a more macro level, are the best means to prove integration and verify performance.  I wrote a paper about this idea, and you can click here for the document.
• And finally user validation: in the end this one may be the most important for user-intensive systems.  Regardless of verification, validation is proof that the user can actually apply the delivered objects effectively to their mission.  To keep it short, I won't expound on "effective" or "mission", but they cover a lot of landscape.  The agilists put the object in the hands of the users and seek reaction and feedback, hopefully in a timely cycle that is virtuous for the next sprint or iteration.

Photo credit: Federal Highway Administration,

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

On leadership

5Whys.com has a nice posting on leadership quotes.  Here's what you'll find there:

 

• You can never cross the ocean unless you have the courage to lose sight of the shore. - Christopher Columbus.

• "If I had asked people what they wanted, they would have said faster horses." ~Henry Ford

• "There is nothing so useless as doing efficiently that which should not be done at all." - Peter Drucker

 

 

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Integrating the risk register with the project

David Hulett has a presentation on his website, projectrisk.com, entitled "Integrated Cost/Schedule Risk Analysis using Risk Drivers".  In this presentation, he develops an interesting scenario involving the risk register and the project schedule/resource plan.

His idea is this: the risk register should not be stove piped as a on-the-shelf database only referred to occasionally.  It should be integrated into the project plan by means of an integrated Monte Carlo simulation that simulates the effects of the risk register on the schedule/resource plan.

Here are the steps:
1. Assign risk distributions to the events on the risk register.  This is more than just a simple PxI calculation.  It means do a three point estimate on each event; the real world distribution, likely unknown, can be modeled as a Triangular distribution for simulation purposes.

2. Also evaluate whether or not the risk event, if it occurred, would actually effect every task on the schedule, or just some tasks, and--here's a twist--evaluate whether or not a true event would actually effect the schedule/cost plan. 

That is, if for example labor rate escalation is a risk event, and it actually occurs, does the escalation really get applied or not?  Perhaps there are reasons that the escalation, even though authorized, would not be applied in every case; only be applied in some cases.  Hulett recommends that the latter assessment be on a continuous scale of 0 to 1. 

With this evaluation, you now have two probabilities associated with a risk event: will it occur, and if it occurs, does it have an effect?

3. Now run a Monte Carlo on the schedule; then, run a Monte Carlo on the risk register; then create an intersection between them.

What do you get?  You get a simulation result that integrates the probabilistic characteristics of the risk events on the risk register with the probabilistic characteristics of the schedule/resource plan. 

A good heuristic is this: when you correlate otherwise independent events, there is a stretching of the timeline.  So, even if you don't go to all the trouble to run such simulations--now supported by automated tools for just this purpose--know this: the schedule will stretch out as the risk register is correlated with the schedule/resource plan.

System engineers know it this way: apply a filter to an event, and the correlating effects of the filter will stretch the event.  Widen the bandwidth, thereby lessening the filter effects, and the event sharpens.

And, if you are concerned about making risk assumptions, and the accumulation of errors around estimates and evaluation of risky events, read Hulett's paper on that as well: "Assessing Risk Probabilities".

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Alegory vs Epistemic risk

Matthew Squair writes about the juncture of safety and risk, focusing--according to his tag line--on emergence, complexity, chaos & technological risk.

If you wondered about some of the $10 words in risk management, and particularly if you are preparing to read something from Nassim Taleb, Squair has a clear and concise explanation of epistemic risk in his posting entitled, conveniently, "Epistemic and aleatory risk".

If you're a safety person, you might want to read a related posting that uses the definitions and concepts in an discussion of the recent nuclear plant debacle.

Of course, if you do read Taleb's stuff, here's his commentary on the nuclear thing as given on valuewalk.com

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

The value of certifications

PMI's Agile Community of Practice [CoP] hosted Alistair Cockburn and James Shore in a debate by webinar on the "Merits of certifications". If you're a PMI member, you can listen to a recorded version at the Agile CoP site by searching for past webinars.

Shore and Cockburn are respected thought leaders in the agile community going back at least a decade.

In a word: Cockburn sees value in certifications, with caveats to be sure, and Shore not only sees no value but actually believes certifications are counterproductive to their aim.

I was a bit shocked to here Shore rip into the very idea of certifications, calling them immoral and utterly misleading, and damning all those that use them as filters. This on a PMI sponsored webinar!

To be fair, here's the summary points each gave at the end:

• Both agree that certification does not demonstrate or indicate competence and maybe not understanding
  
• Alistair Cockburn: a certificate:
  is evidence of having gone down a pathway of education
  permits or enables scale to be applied to examining large numbers of candidates, or a company, for a job
  encourages individuals to re-up on latest techniques
  should be valued according to a market value established by business and hiring officials
  should be more granular, like associates and interns, etc so that the value proposition is more readily established
  
• James Shore: a certificate:
  leads to institutional stagnation
  creates institutional power structure that limits advancement
  confuses competence and expertise with simple exposure to information
  should not be a filter on considering a candidate for a job
  should not substitute for due diligence, even at scale

I find myself in both camps: I agree a certificate does not indicate competence, or even predict competence. Same for a college degree; although in a bridge-too-far Alistair argues that a degree is just another form of certificate. No, I'm with Shore on that one. It's not.

And I'm with Shore when he points out that the industry that promotes "Scrum Master" certificates for $1500 and a two day sitting in a hotel room presentation is pretty much a joke on everyone except those collecting the money.

But I'm strongly with Cockburn on the value of forcing a re-up from time to time. Even Shore see merit in the education, just not in the certification of the education.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

Explicable but stupid!

I'm not the greatest fan of Jurgen Appelo, but I think he does think and write some good stuff from time to time.

However, he was recently denied entry into the United States because of his work status...an independent training contractor!

How could this be the case? Gross stupidity on his part, or on the part of the United States immigration law?

The answer is: YES! 

For a smart guy, Appelo was unwittingly(?) ignorant.  10 minutes on the State Departments visa website would have told him he was steering into troubled waters. (See below).  And yes, for a country that values technology and those that practice it, we are stupidly denying ourselves of talent.

In his words, describing his interview with a immigation official:

But no, the reason was that a self-employed independent trainer is not allowed to “work in the USA”. The government official (who was very kind to me by the way) explained that “the rules are unfortunately stacked against independent consultants”. He tried to find loopholes, but there weren’t any. It didn’t matter that I have a company and a US tax number. And so, until somebody changes the law, he said, he had to send me back home. Even if I applied for a work visa, I wouldn’t get it, he told me. Work visas are usually given to people working for bigger companies, with legal entities in the US. The easiest thing to do would be to hire an American person to give my courses in the USA.

A special case? But no! Reading the comments on his blog about this, apparently this is routinely the case, especially with trainers. I thought we valued diversity and education in this country.

Now, a review of visa requirements at the State Department visa site makes it pretty clear (I wonder if Jurgen bothered to read before travelling?): Europeans [and many others] can enter the U.S. without a visa, as Jurgen intended to do, for tourism.  But for any other purpose a visa is required. 

Now, a B-1 visa is issued for business purposes, but strangely enough some special interest got training-for-a-fee specifically excluded from the B-1 (training for no fee is ok and within the B-1!).

That leaves the H1-B and O-1 visas which are for 'temporary workers' who are persons with special science, arts, and other enumerated skills (so far as a lay person like me can fathom).  H1-B's are limited by law and there is a waiting list of petitioners, so that would seem to be a dead end.

I have no idea how difficult it is to qualify as a specially skilled artisan or technician for O-1 purposes.  Maybe you just fill in a form and press on. (State has a website for online application for visas for non-immigrants) But why does it have to be so complicated?  Explicable, but inexplicable.

The immigration thing is like the TSA: beyond practical comprehension.

 Bookmark this on Delicious  

Another business value v earned value misstep

PMI's Aerospace and Defense Community of Practice (CoP) hosted a webinar in May entitled: "Considerations for Using Agile in a Government Contract Environment", meaning for the most part a U.S. government contract, as different from state and local contracts and non U.S. contracts. If you're a PMI member, you can join the 'A&D' CoP and then click on past webinars for a recorded version.

Now, about BV vs EV: In fairness, the webinar presenter, Peter Brosella, said he knew little about earned value. He then proved his point by putting up a slide with a chart of earned value vs time and labeled it 'business value'. His description of the slide was more about business value than earned value, but he discussed both ideas without really distinguishing between them. And, none of the 100+ PMPs watching in real time took the issue on. (I tuned into the recorded version last week) What does that say?

It says there continues to be rampant confusion in the Agile community over the 'value thing'. It's really not that hard. Business value and earned value don't measure the same thing, and they don't measure in the same time-frame, but they use similar words. One more time:

• Business value is about earning a return over time from the investment made in the project, to include the continuing post project investment to maintain and support the deliverables.  
  
  Business value improves the balance sheet.  Why?  Because customers add to assets by buying the product--if it's a product for sale--or employees place fewer demands (liabilities) on the business because operating efficiency is better if the deliverable improves internal operations.
  
  
• Earned value is about getting your money's worth by transforming an investment into a deliverable that has the potential for business value attainment.  "Transforming an investment.." is what is otherwise known as the project process.  EV is the value placed by the sponsor/investor on the deliverable that has intrinsic but unproven business value. 
  
  Consider the timeline: At the moment a deliverable is made operational, whether at the end of a sprint or iteration or other project milestone, it's accumulated an 'earned value' but has earned nothing in business value.  So, at the moment of delivery to production: EV = some proportion of budgeted value, and: Business Value = zero.
  
  By some accounting measures, EV should have no effect on the balance sheet.  Money assets are transformed--by the project process--into other asset classes of equal value, thereby not affecting the balance sheet at all.  Only if the actual cost, AC, is greater than EV would the balance sheet be affected.

There have been so many posts and counter-posts (see the thread on Glen Alleman's Herding Cats) on this 'value thing' of recent that sometimes it seems like agilists are like teenagers who've just discovered sex and are sure they've done something unique that generations before somehow missed.  And, like teens, it takes years and a lot of experience before it realized that the world did not begin in 2001 in Snowbird.

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.