Shift risk management forward

By Andrew Clifford

We can reduce risks by shifting our management of risk to earlier in the system life cycle

As a generalisation, project staff take too many risks and support staff take too few.

Designers take too many risks. They use the latest tools and the latest design approaches. They write their own frameworks and components because standard ones are "not good enough". They use advanced features and extensions to get the best out of the technology. But new, unusual or unique designs are hard to support.

Project managers take too many risks. Their view of risk is limited to project delivery: being late, over budget, too few "resources", that sort of thing. In the name of risk, they cut back on testing and documentation because of delivery dates. They are not concerned with the long-term risks of the solution. But if they are not managing long-term risks, who is?

Support staff take too few risks. They do not upgrade to the latest operating systems. They tack on new bits of program and data, rather than re-engineering the whole. If new technologies come along, they use wrappers and compatibility layers. They make as few changes as possible, just in case the system breaks. "If it ain't broke, don't fix it" is their motto. But without re-engineering and upgrading, systems soon age and die.

I understand both. Project staff are judged on their ability to deliver on time and to budget, to meet requirements, and to use modern and fashionable technology. They are rarely judged on the long-term consequences of their decisions.

Support staff are judged on their ability to keep systems running without problems. They accept gradual decline and early obsolescence, rather than proactive maintenance that could keep systems running for longer.

Although it is understandable, it is not good. We need to shift our awareness of risk to earlier in the system life cycle.

Part of this is about changing our definition of risk, seeing not just project delivery risk but whole solution life cycle risk. Project managers in particular need to worry less about delivery and more about what they deliver.

You can rebalance risk by involving support staff in projects, or getting project staff to work in support. There may be some friction between the different viewpoints, but this is a good thing. Working through the arguments helps build much better systems.

You can assess projects for whole life cycle risks. The ISO 9126 standard contains a useful breakdown of quality that includes long-term risk factors like maintainability, as does the system governance system review. This type of assessment encourages risk reduction practices, such as using only well-established conventional technology and building comprehensive test packs.

If we make projects more risk aware we reduce risks during support. Systems are more conventional, easier to understand, easier to change. It is no longer too risky to upgrade, or to re-engineer the solution. Proactive maintenance makes sense. Systems can be kept in good condition for longer.

Shifting risk management is a challenge, but one that we must rise to if we want to deliver systems that meet their full potential.

Subscription