Risk Management: something new?

When Tony Hayward became CEO of BP, in 2007, he vowed to make safety his top priority. Among the new rules he instituted were the requirements that all employees use lids on coffee cups while walking and refrain from texting while driving

 

The quote is the opening paragraph in an article in the June 2012 edition of the Harvard Business Review by Robert Kaplan (Balanced scorecard co-author) and Anette Mikes entitled: "Managing Risks, a new framework"

I'm not sure there's all that much new here, perhaps nothing new at all, but here's a summary of the framework:

There are three categories of risks:

1. Preventable risks for which there's no business upside per se. Coffee cup lids go in this category
2. Opportunity risks for which there might be substantial business upside: programs and projects for 10,000 foot deep water wells belong here
3. External threats over which there is little or no control, but may require defensive measures: tsunamis fall in this category.

Preventable risks are the work of safety committees, standard policies and procedures for behavior and the like, health and welfare HR folks, and a myriad of workplace specifics like blow-out protectors that actually work.

If you do all this, you may not attract or retain a single customer. If you don't do this, you may spend a lot of money on non-value add adjudicating the misfortune of you and your associates. It may sound counter intuitive, but attention to preventable risks is actually lean in the long run. See: BP, stupid maintenance tricks; and Air France 447, pilot training?

We all know about opportunity risks. That's either making a decision to take a risk, or planning a risk response for an opportunity already being exploited, or estimating a risky outcome for something we've elected to do. ISO 31000 and the PMBOK Chapter 11 cover this ground pretty well.  So does Edmund Conrow.

The thing about threat management is that there's too little attention paid to upkeep and maintenance of things that are supposed to work (infrequently and under stress) and there's too little attention paid to readdressing assumptions, environment, etc. Perhaps the countermeasures aren't even relevant anymore. How do you know?

So, perhaps the thing that's new here is the rearrangement of the dots which brings about an alternate narrative. That may be enough to make this framework worthy.






Bookmark this on Delicious

Process is a child of scale;

When your playing small ball, you don't need a lot of process. Just put them all in a room, close the door, and shove pizza under the doorway every few hours. Apply a little bit of heat, and then wait for results.

But, if you are playing with other people's money (OPM) and you are doing something that isn't trivial, then you need some process.

---

Process is a child of scale; that to have the latter inevitably brings the former.

And so what's a process? For sake of discussion, let's call it a transformer: Put something in; grind a bit; and whatever you put in is dramatically transformed into something wholly different. It's almost as if "miracle occurs here!".

Money, time, effort goes in; stir with a few steps and controls and policies, and there it is: DONE deliverables!

But transformers are tricky devices, suitable only for adults who think critically. There need not be more transforming capability than is necessary to get the results. That's where the scale thing comes in: larger scale, more at stake, more investment in process. And a little feedback is necessary to stabilize the process; in other words: no open loops!

One project I was on did something remarkable that I've come to appreciate: each new thing we did was preceeded by a process briefing. Someone got us all together in the war room; a one page map went up on the screen, and we stepped through it. Something of a dry run. Sometimes, we did some real-time editing; always we went around the room for concurrence. Did we have a "green board" and we could proceed? Or, did we have to bring someone along?

It's a great thing when a plan comes together. And, come to think of it, it's swell to have a plan, a process, a roadmap...whatever you call it, but it's the guidance for the whole crew.

And, more scale, more people involved, more attention is paid to the network, the workflow, and the validation.

And, more pizza!

Image: http://3bblognews.blogspot.com/2010/09/pizza-and-reading-yummy.html

Bookmark this on Delicious

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

Best value: the concept

I recently had a short debate about "best value" versus "best effort. It's always important to be clear about terminology--words are important--but it's most important to get these ideas clear when it comes to Agile, because 'effort' and 'value' really aren't the same:

In Agile, the grand bargin with the project sponsor is to deliver "best value" at a fixed cost in trade for latitude to evolve the scope details. The concept is like pick of the litter: "the most valuable deliverables" from among all the possible deliverables.

Of course: who says it's "best"? Answer: the customer, or the one holding the customer's proxy.

At each iteration, the customer goes through the backlog and reprioritizes and may invent new things. New things are all put in a backlog stack. The totality of the stack is compared to remaining time and budget. (Mix in a little technical debt to add seasoning to the backlog) At some place in the backlog stack you draw the line--actually, the line gets redrawn at every iteration if anything changes, which it will. Above the line, things get delivered; below the line: there's always V2.0!

At the end of the project, the customer has picked the best value from the backlog. Anything not done is of lesser value than those that were picked.

So what's best effort? Best effort has been around a long time. All cost-plus-fixed-fee (CPFF) contracts are legally 'best effort'. The contractor's responsibility is to apply best effort to the defined scope (defined by the customer in the SOW and specifications); if it doesn't get done, then the sponsor has a decision: bring more money, or terminate the effort. The contractor has no obligation to finish on his own dime.

To the uninitiated, best effort sounds crazy, but actually it works quite well to get difficult jobs done; but it's not the same bargain as made in Agile. The best effort bargain is to bring the best and brightest to the problem and work as responsibly as possible, but at the end of the day, the sponsor is on the hook for the money to finish.

So, where's the rub? It's in the opportunity cost. For the contractor, the fee (profit) is fixed; the contractor can't get richer on a better job, nor poorer on a bad job. In other words, it's economically regulated from the contractor's point of view. Nobody can get "Facebook rich" on best effort like they could on best value.

Bookmark this on Delicious

Agile and US Federal Government

During one of my recent agile project management classes, a student contributed this posting:

[For acquistions sponsored by the] Federal Government, all systems--especially if they deal with life or death or classified data--have to receive an Authority To Operate (ATO) signed by a Designated Approval Authority (DAA)......

 

  

The National Institute of Standards and Technology (NIST) establishes the cyber security guidelines that all federal agencies have to follow. Each agency then tailors these guidelines to meet their particular needs. There is an extensive amount of documentation that is reviewed during the C&A process including the results of security testing.

 

  

• System Security Plan
• Risk Assessment
• Security Test & Evaluation Plan
• Security Test & Evaluation Report
• Continuity of Operations Plans
• Business Impact Analysis
• Privacy Threshold Analysis (PTA) and/or Privacy Impact Analysis (PIA)
• Rules of Behavior (privileged)
• Rules of Behavior (end-user)
• Security Assessment Report (SAR)
• Configuration Management Plan

 

  

.... The way this is handled within my customer’s agency is:
Sprints are generally 4-6 weeks long and produce a package of functionality, multiple sprints create an iteration, and multiple iterations create a release.

• The release can take anywhere from 3-6 months. The release goes from the product development organization to a separate release management organization which is responsible for coordinating the release of the product into production.
• The release management organization coordinates the C&A activities with the security organization.
• All these organizations are under the CIO but operate pretty independent.

 

Most of the actual development is outsourced to private industry so there is a varied role of the government staff in the Agile process. Since a lot of what the government staff does is contract oversight, the most likely role is as Product Owner Representative.

• The actual Product Owner is outside the CIO organization in one of the agencies business areas.
• For each project, the agency has created an Integrated Product Team (IPT) which has agency representatives from the business area, security, release management, architecture, etc. The project manager generally leads the IPT.
• I see the government project manager being heavily involved in developing the Product Backlog and to a overseeing the development of the Sprint Backlog but it is really up to the contractor to manage each Sprint.

[....]

 

It is a really interesting challenge to figure out how to take this agency to a more Agile environment. Not only is it helping them with the technical issues of implementing Agile but also with the biggest challenge which is the culture and organization change issues. Agile will have to be implemented incrementally over time and the agency may never reach a full Agile state. We are working with them to identify and implement those pieces of Agile that will provide the most benefits first and then continue the improvements.

 

[... ] The areas of the life cycle that I am trying to better understand are in
(1) project definition and approval,
(2) establishing the system architecture, interfaces to other systems, and data base architecture, and
(3) system level testing during a formal release cycle especially when there are major cyber security concerns (classified data, life or death considerations, financial data).

Much of the Agile training assumes that the project has been approved and is ready for coding; does not address a formal release cycle; and focuses at the team level.

 

I have started to review “Agile Software Requirements” by Dean Leffingwell which discusses the Agile Enterprise Big Picture and presents a scaled Agile delivery model at the team level, program level, and portfolio level which provides additional background.

Bookmark this on Delicious

Innovative construction

Silly me. I actually didn't know that there is a whole industry around something called "accelerated construction" in transportation projects (roads and bridges). It seems like these program guys have come up with the ultimate schedule fast-track.

I stumbled on this reading about fast projects for bridge construction. It turns out, there's a lot of them. And the reason seems to be economics (no one has any money) driving fast (read: cost efficient) solutions, or perhaps solutions (read: new methods and technology) making it economical. I'll leave the chicken and egg argument for someone else.

Nevertheless, accelerated construction is a project phenomenon that is being moved along by these factors:

• A US federally funded Accelerating Construction Technology Transfer (ACTT) Program
• Pre-fabrication (nothing new, but part of the plan), and
• SPMTs (self-propelled modular transporters) which are multi-axle, computer-controlled platform vehicles that can move bridge systems weighing up to several thousand tons with precision to within a fraction of an inch. (Let's hear it for GPS!) The vehicles can move in any horizontal direction and also have vertical lift.

Now, down here on Florida's space coast, we know a thing or two about large scale transporters: after all, moving the space shuttle around was no small matter

But, in the bridge business, having the right transporter technology is perhaps the one project tool above all others that makes the rapid schedules workable.

From the US Federal Highway Administration website, we learn a few case studies:

• Sam White Bridge over I-15 in American Fork, Utah - In March 2011, the Utah DOT (UDOT) used two sets of SPMTs to lift the Sam White Bridge across eight freeway lanes of I-15. This was the longest two-span bridge ever moved by SPMTs in the Western Hemisphere and was UDOT's 23rd use of the technology.
• Massachusetts FAST 14 Project - The use of accelerated bridge construction, prefabricated bridge elements and the design-build project delivery method enabled the Massachusetts DOT to shrink a four-year bridge replacement project to just one summer. The $98 million project, dubbed "Fast 14," involved the rapid replacement of 14 deteriorated bridge superstructures along I-93

In a few words: bigger is usually better! Let's hear it for transporters.

Bookmark this on Delicious

Unmanaged risks

On any project there are going to be dozens, perhaps hundreds, of unmanaged risks (I doubt this is news to anyone):

• Weaknesses that are Low-Low on the risk register's probability-impact matrix, maybe even all the way to High-Low (p-I)
• Threat events or their effects that are off baseline, not in the project plan, and range from Low-Low to High-Low, perhaps even Low-High also (p-I) 

So, you've not put the unmanaged event or its effects in the project plan, but you have identified the risk and put it below the line of those risks that you will actively manage. Among the four big strategies--accept, avoid, mitigate, and transfer--which one is being used in this management scenario?

If you picked "accept", you get the risk manager's prize for this posting. Indeed, this is 'acceptance' of risks that are below the line and not being managed.

Frankly, for many, the idea that we're going to sit back and accept risk is an uncomfortable position to take. But it happens all the time. When my risk management students lament that their organization has no risk management process or strategy and just deals with risk as they come along, I respond:

"No strategy" is a strategy of sorts in the sense that you've embraced "accept" as your risk response plan. In that event, the need to actually do a lot of work up front to identify risks is really not too productive. If the organization is risk-seeking in attitude, this may be just fine. After all, you're just going to accept whatever comes along and deal with it.

Now, assume one of the unmanaged risk events occurs, and there's some effect to the baseline; now the risk is an issue (issues being in the present, and risks being in the future). Now, you manage the effects of the issue. Is there anything you should have done in the plan, anticipating that your strategy is more about issues and less about risk?

Actually, yes: if your target is issue management and not risk management you can still take a page out of the RM manual to prepare:

• Maintain a vigilant 360 awareness to give you some runway on issues
• Keep your powder dry by holding back some unallocated reserves
• Buffer the schedule in the areas you predict are key to project success
• Keep conjunctive events at a minium (planning strategy)
• Have a good idea in mind of a conflict resolution process that you can bring to bear during issue debate and resolution

Does all this mean that unmanaged risks are actually part of the plan and you're just deferring the inevitable? No, unmanaged risks are just as uncertain as anything being managed. Some will happen; many will not. But letting them become issues rather than managing them as risk, you've limited your options in two ways

1. The runway is shorter than it need be
2. Risks that could have been avoided may not avoidable

Seems a little short-sighted, but no risk strategy is a strategy

Bookmark this on Delicious

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

What's that agile thing?

Every agile discussion is dominated by two questions:

1. What is agile;
2. Why agile?

The first question is answered this way:

Agile is a name given to a number of different methodologies that are all responses to the answer to the second question. Though agile methodologies differ in many respects, they are composed of both management practices and technical practices.

These practices are not too much different than those we know from the PMBOK. However, they are arranged in unique ways, given different priorities and names and relationships, and so the project management narrative is quite different even though the constituents may be familiar.

In effect "old dots connected in new ways" = new narrative, but the new narrative is why agile is effective.

The second question is the more important:

Agilists say that the predictability offered by traditional methods is a myth, that predictability is not really possible. Predictability of cost, schedule, and scope is problematic because of these two reasons:

1. Requirements paradox: we want requirements to be stable; but (user) requirements are never stable. But, other non-user requirements taken from standards, infrastructure specs, and the like can be, and usually are, stable. So, requirements are like a layered structure: the bottom layers are usually stable; it's the user layer that's not.
2. Systems (of requirements) have chaotic and emergent properties, actions, reactions, and functions/performance. These emergent actions and reactions are simply not predictable; they can only be experienced. Once revealed they can be dealt with.

Agile deals with these two problems these ways:

• A bargain is struck with the project sponsor (call this a business case): in trade for the flexibility to handle user requirements as evolutionary and emergent, agilists pledge that they will deliver the best possible value (not a specific scope) within the time and budget given by the sponsor.
• Requirements (in the form of stories) are discussed conversationally with developers. When understanding is reached, the conversations are then frozen in time boxes and developed to the point of DONE; then the backlog is unfrozen, a new batch are selected, and 'do again, until ...' ("Done" may be an alpha release, a beta release, a prototype for a focus group, or a production release)
• Estimation depends on benchmarks of past performance on similar stories.
• Time box performance by teams depends on the teams sticking together and practicing together so that their performance over the duration of a timebox is predictable.
• Users exercise the system to tease out the unpredictable; these then become 'debt' in the backlog, to be prioritized with other requirements
• Verification is done incrementally; validation is only done at the project epic narrative level

Bookmark this on Delicious