Technical Risk Management

While reading Waltzing with Bears, I realised that I had never done any rigorous risk management over technical risks. There are many common risks I can think of even without trying. For example;

• selecting wrong middleware or servers
• sup-optimal architecture/design assumptions
  
• a module or component fails to deliver due to complexity or dependency
  

PMs/IMs generally own the risk register and the register usually excludes technical risks due to their lack of technical knowledge. I believe the technical risks should be managed with the same level of focus. I'm not sure it would be better to include the technical risks in general project risk register or to manage in a separate list managed by technical team. One thing is sure that I can improve my technical risk management better.

Set-Based Concurrent Engineering (SBCE) anyone?

Waltzing with Bears Part I

Gems from Waltzing with Bears by Tom DeMarco & Timothy Lister.


If a project has no risks, don't do it.

Risk management is project management for adults.

The word maturity has nothing to do with technical proficiency. It is, rather, a quality of grown-up-ness, ......

A risk is a problem that has yet to occur, and a problem is a risk that has already materialized.

Risk management is the process of thinking out corrective actions before a problem occurs, ...... The opposite of risk management is crisis management, ......

Risk Transition: the point at which the risk materialises.

Transition Indicator: the visible event at the time of risk transition.

Component activities for risk management

1. Risk Discovery: initial risk brainstorm & subsequent triage
2. Exposure Analysis: quantification of each risk (probability & impact)
3. Contingency Planning: what you do if it materialises
4. Mitigation: steps that must be taken before transition in order to keep your options open and to make correction possible afterward.
5. Ongoing Transition Monitoring: tracking of risks

The worst organisations penalise unappealing forecasts, but not unappealing results.

Without risk management, projects have no way to distinguish between stretch goals and reasonable expectations.

Before any risk management. Speak the words "failure", "rejection", and "cancellation". If the words do not come out easily, you have cultural problem!

When you choose to ignore a risk, you're depending on luck.

Reasons to ignore a risk:

1. The probability of materialization is small enough to ignore.
2. Should the risk materialise, it makes the effort under management irrelevant.
3. The risk has minimal consequences and requires no mitigation.
4. It's somebody else's risk.

When a project comes wrapped as a challenge, it forces you into a posture of counting on a certain amount of luck.

Limiting the extent of your losses in software project work is more important, on average, than doing anything about your wins.

Project for Success

Questioning the Role of Requirements Engineering in the Causes of Safety-Critical Software Failures by C. W. Johnson and C. M. Holloway questions the usual blame placed on inadequate requirements engineering for software project failures (safety-critical software). The paper is here.

The paper then presents the following list as root causes of the project failure identified incorrectly under inadequate requirements engineering.

1. lack of stakeholder involvement
2. incorrect environmental assumptions
3. communications failures within development teams
4. inadequate conflict management
5. lack of contextual detail

I find #4 interesting in particular. We suffered a bit from #4 in current project. The project required input from different departments (marketing, operation, client service and etc) which had different interests. It was a difficult process to draw a decision to everyone's satisfaction. The lesson was to work out conflict resolution process early among stakeholders.

It is a great checklist for early phase of a software project and a great starting point for discussion with project sponsors & project leaders.

See Alistair Cockburn's blog about the paper.