What’s your fifth risk? — Unexpected problem cause big problems

“Life is not what you expect: it is made up of the most unexpected twists and turns” — Ilaiyaraaja

Projects are fertile breeding grounds for problems. Ingredients such as groups of people working to tight deadlines, using new technology/features with no experience and lots of activities happening at the same time.

Some problems go off like a hand grenade, grab everyone’s attention and demand to be resolved quickly. Other problems hide in the background, sleeping, and then when everyone is looking the other way they unexpectedly cause enormous problems.

What’s the unexpected risk that will disrupt your project?

Like being hit by a car you didn’t see, the surprise doesn’t give you time to plan or react.

In Michael Lewis’s book the The Fifth Risk: Undoing Democract it puts forward the idea president trump is a risk manager and the government official who works in the many departments manages risk.

Lewis interviews government officials in roles such as the department of energy and asks them for their top five risks. Most people can reel of four risks quickly but when they get to the fifth, they struggle and have to do more thinking. Lewis highlights this

“And I thought, that’s the fifth. The risk you’re attending to, the risk that’s top of mind, is not likely the thing that’s going to actually kill you. The fifth risk is a scary one because it’s the thing you’re not paying attention to.”

The fifth risk is a long-term risk that with gradual mismanagement could grow into a large problem. What are the risks you aren’t expecting, what’s my fifth risk on the projects and work.

It works, it works, it works, then boom it doesn’t work. these problems cosy up close to you causing you to let your guard down before they go wrong with devastating effect. No one saw the big problem until it exploded.

I have seen many ignored problems suddenly turn into a large problem. A project left on debugging on a Dynamics server, every day it would log out hundreds of lines of logs which no one looked at. This was a small problem, which someone was going to get around to fixing at some point. One day no one could create any new records in Dynamics, the problem it turned out was there was no more space on the Dynamics server because it was full of 2 years of log files no one was looking at.

The coronavirus was unexpected but so were peoples reaction. If everyone had brought the same amount of food, pasta and toilet roles as before, no one would have run out. Instead some people started buying extra, which panicked others to buying extra which resulted in empty shelves and some people who couldn’t buy any toilet roll.

“On February 1, 2003, the U.S. space shuttle Columbia disintegrated when reentering the Earth’s atmosphere, killing all seven crew memberes. Columbia broke up because a piece of foam insultation broke off during the launch and damaged the shuttle’s ability to protect itself from heat on re-entry. The problem of the foam debris was not new, but since nothing bad had happened in the past, the engineers overlooked the issue. Rather than considering the risks from the debris. NASA took the lack of problems as evidence that everything was ok.” Michael J. Mauboussin — Think Twice: Harnessing the Power of Counterintuition

The nature of these problems is they don’t initially seem worth worrying about, people overlook these problems as minor annoyances and something to clean up later when we have more time. Some problem can leave a gap open for a bigger problem to occur or the small compounding of the problem grows until it becomes a big problem.

A common problem on IT projects is the lack of standards or lowing of standards. Initially the effect is hidden by time, the complexity of the solution gradually increases. Standards code and customisations are written consistently to drive quality.

No standards creates customisations/code in different ways, different naming. The system becomes harder to understand, taking more time to debug and extend. Every new customisation takes longer, more bugs appear, and each bug takes longer to resolve.

Eventually the cumulative build up of low quality code/customisations will result in the customer considering moving to a new supplier and rewriting the system. Death by a 1000 poor lines of code rather than one fatal bug.

All nations were warned of a pandemic, many did test runs and found they did poorly but few changed the infrastructure to prepare for an outbreak. When a pandemic strikes, it’s too late to prepare because it can quickly overwhelms the heath service.

The best time to fix a hole in your roof is when it’s sunny.

The shortages in PPE equipment, ventilators , testing facilities, tests could have all been prepared for. It’s time to build

1. Relationship with the customer
2. Scope growing out of control
3. Missing requirements
4. Impossible deadlines
5. Low standards
6. poor leadership
7. technical limitations

1. reduced sales
2. High churn rate/people leaving
3. Poor leadership/lack of engagement
4. No strategy to win
5. Behind the technology curve

1. Missing non function requirements
2. A solution that doesn’t work
3. A solution not scalable
4. Bottle necks
5. Uncontrolled scope
6. Your knowledge not keeping track with technical change

1. The project leadership
2. poor estimates
3. Technical debt
4. Poor requirements and missing requirement

The fifth risk will be the small changes which don’t seem important enough to stop. This gives them time to grow and hide, until one day a massive problem explodes and chaos ensues.

The problem that causes the most disruption is the one you didn’t expect.