Are you managing the right risks?

I was talking to a very good Project Manager the other day. We were talking about the risks that a Project Manager manages in the delivery of software.

In a traditional project, the risks managed are often not actually the biggest risks that project will have. Some possible risks that the project will have are:

• The thing you’re building will not be used to generate the benefit you think it will deliver (this is the biggest risk)
• What you’re building will not be liked by customers – it won’t solve their problems
• They’ll find something better or something that is available sooner but is not-as-good, which they’ll start using and be reluctant to switch from this to your product
• The thing that you deliver will have obvious ‘gotcha’s: once you see it working, you’ll realise it would never have worked the way you’d envisioned
• People use it in a way that you would never have imagined and you have to change all your future features based on how people are actually using it

Technical risks

The other sorts of risks the project will have are technical risks:

• It will never scale
• The development team you have in place aren’t capable of delivering a solution
• The amount they quoted to do this is nowhere near enough to deliver it
• The software you’re using is not fit for purpose
• The production environment won’t be ready in time

And how about...

• The various components you’ve been building don’t integrate well together – one development team has misunderstood how the interface to the other development team’s work will work. One team is sending apples and the other team is expecting oranges.
• The amount of things you have to prepare in I&O (Infrastructure & Operations), security or pre-production are so numerous and you didn’t realise you had so many hurdles to jump over before you could put this into production.
• The requirements you’ve received have now gone out-of-date and are stale. You had a team working on the requirements, they haven’t synched and some requirements documents have been moved forward after review and others haven’t. The whole thing doesn’t string together, end-to-end.
• What you thought was absolutely critical, when you were writing the requirements document, turns out to be irrelevant in the new world.

An Agile approach

These are the sorts of risks that an Agile approach highlights early on. Agile gets a bad reputation for pointing out that there are all these risks. People don’t like seeing a lot of risk. They prefer to do something in a more “risk-free” environment where things are steadier and planned further.

All we’re really doing is pushing the risks that we know exist under the carpet and revisiting them later.

Agile means we see the risks that are already there (whether we choose to look directly at them or not), understand them and change tack quickly before the risk becomes a product-halting problem.