Risk management is a day 0 activity

This morning I was participating in a Mentisor seminar/roundtable activity on Risk Management and Scope Management.  Both subjects are basic project management topics that often don’t receive the attention they deserve given the mayhem that neglect may cause.  This got me to reflect on a conversation I had a few months ago with a client that got badly burned.

In my line of work system validation is mandatory and very expensive compared with hardware/software/programming costs.  The numbers vary and each of my clients has its own pet number but it is typical to add 170%, 200%, or even 220% to the purchase cost just to account for validation.  In hard numbers this means that a $1M system will cost $2.7M to $3.2M by the time it is validated and rolled out.  If the system is more expensive; you do the math.  It can get scary pretty fast

A side effect of this multiplier is that clients understandably fight scope change tooth and nail.  We do the same; no one wants to be the donkey in a game this pricey.  The title of this post being “Risk management is a day 0 activity”, you are probably wondering where I am going with this?  Well, the wait is over; some best practices related to Risk Management and Scope Management should avoid a lot of wasted money:

• Risks are built in the project approach; a project or product is not a repeat activity and some of this innovation is likely to have unrecognized risks. Recognize this from day 0.

• Avoid Swiss army knife software; there is no software package that does everything well and all those marginal features will still need to be tested and validated ($$$). What is the likelihood that some of these features are putting you project budget or schedule at risk?

• Avoid stakeholder’s pet feature for the same reason as above. I’ve had requests for reports that have the same content but packaged differently; keep only one variant and let the people adapt. There has to be a positive aspect to that Evolution thing.

• If you can’t avoid the two previous points, identify those features that are risky, track their triggers diligently, and the minute those triggers engage let the project sponsor know. You may be able to jettison them before they really hurt the project or at least to minimize their impact.

• Remind your stakeholders that featuritis is costly to implement, to validate, and to live with over the live of the product or system. Remember COBOL, FORTRAN, etc? Systems written in those languages still need to be “fed” years after rollout by old guy like me who will retire eventually.

Don’t tell me that these points don’t ring true and that they don’t represent situation that repeat themselves, with predictable outcomes.  Recognizing and managing risks from day 0 will save you a lot of aggravation and costs.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkedIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Comments

[David]

What the heck is day 0? 0=nothing, nada, zip. Perhaps you mean day 1? The first day: before the first there's no project, so no action is possible, is it not?

[Patrick Richard]

Hello David,

Not to split hairs but Day 0 is often meant to mean anytime until the first day is over. For example a Day 0 software virus.

Anyway, Day 0 or Day 1 is fine by me; I meant to convey that risks have to be considered from as early as the start of a project.

Let me float an idea here; what would you call a risk that is identified before the project is launched? Would a risk that is identified an the portfolio management level be a Day -x risk?