RISK Management in product Development

Vicious and Virtuous snowballs

Developing products could be a most fulfilling experience full of excitement and growth opportunities. Yet often they become a framework for contradictions; unexpected delays, deviations in budget, confronting opinions about the best way to plan ahead, inability to achieve closure or handover, and unbelievable amounts of defects and fixes affecting quality, budget and delays.

In my years of experience, all these often happen out of the best of intentions – everyone wants the project to succeed! However, good intentions without proper coordination and alignment, create a highly volatile reality for product development teams. And one crucial aspects at the core of all this is that of risks management.

On average IT projects overrun budget by 27%

(HBR 2011)

At least one in six IT projects turns so bad that they can threaten the very existence of the company.

(McKinsey 2012).

snowballs OF risk

I find it useful to think of project risks in terms of snowball effect, but it’s not always about problems. A snowball effect amplifies the impact of events and at some point, gains momentum such that it might smash achievements, but also could knock off obstacles.

I particularly like the risk definition from PRINCE2 book, which defines project risk using two possible but uncertain events: threat and opportunity. This is a powerful approach because it allows for managing both positive and negative impact.

[A risk] consists of a combination of
probability of perceived threat or opportunity,
and magnitude of its impact on objectives

What is a (project) risk?
Managing Successful Projects with PRINCE2®

Identifying project risks early in the project allows managing them and, acting upon them with mitigations. This leads to both avoiding threats or painful scenarios, as well as utilising opportunities to increase the chances of fantastic outcomes.

Vicious and Virtuous events

The way risks are managed, or unmanaged, will impact the events you witness throughout your product development journey. The more unamanaged they are, things tend to feel out of control, and teams would even believe it’s up to bad or good luck whether they fail or succeed.

In order to manage risks I tend to categorize the impact of project risks on objectives according to the following scales: Planned vs. Unplanned; and Owned vs. Unowned. One scale measures how much thought is put into planning risks, the second scale measures how much openness the organisation allows for ownership problems and suggestions to improvements when setbacks do occur.

Unplanned and Unowned = Disaster

When there's no planning for risks, and teams don't learn from those mistakes to assume ownership and make improvements, activities end up usually with disasters.

A relatively recent story was that of the expansion of Target into Canada between 2013 and 2015 which cost the company $1B and closing the operation due to huge retail rent while having empty shelves. The project failure was traced back to two technical obstacles: using a new separate database from the one already used in the US, and underestimating the impact of numbers representation with different currency and a metric system in Canada.

Planned but Unowned = Penalty

When teams start planning their activities and risks, but don't implement or measure the mitigations, they end up spiraling out of control – these are the materials for excuses and blame games, often expressed as “elephants in meeting rooms”. Projects suffer from cycles of penalties and confidence deteriorates going back on track seems out of reach.

When a setback occurs, everyone can honestly claim they were right, yet the outcome is hurting everyone. Probably the Myki project to replace the ticketing system in Victoria could fit this category, going $0.5B over budget and 8 years deviation.

Unplanned but Owned = Change Management

These teams may not be well organised but learn quickly to own and contain problems. Activities of followup arise when risks backfire, and then owned and managed at a cost. However, it feels like constantly putting off fires.

Usually when changes or fixes are introduced; they feel good at the start (averting from a collision with the iceberg) but leave a taste of unease, and time after time could turn into hidden bitterness or obvious rivalry, affecting rapport within the organisation.

Planned and Owned activities = Viable Planning

Such organisations and teams leave minimum to chance or surprises, in this approach managing project risks is an integral part of the milestones. Virtuous risks add certain activities or even requirements to the product's plan, and vicious risks you want to avoid may add mitigations to implement. To an outsider it looks like taking a risk, but to the progessional lead it's merely following a I find Tesla to be a leading organisation these days in this regard.

To be sure, there are security risks with software cars, as with any kind of connectivity. But Tesla could expand its leadership role by modeling how to manage those risks effectively.

HBR - How Tesla Sets Itself Apart - Feb 2020)

viable planning

There are various types of risks in a project

• Technical: feasibility of technology, failure of a components, feature, complex integration, performance consideration depending on power, memory, etc. and more.

• Hazards: actual harm to user or operator using the device. There are detailed and specific standards to categories of devices and the usage risks associated with them to certify such a product; this is also relevant to software in medical devices for example.

• Project: scope creep, retaining resources and talent, buy-in of stakeholders, quality acceptance, IP and patents, and more.

• Business: cashflow, competitors, market acceptance and expansion, agreements and commitments, suppliers backup options, and more.

My approach is that identifying risks and following up on their mitigation is not less important than identifying features. Both risks and features should derive from the clear goals and objectives of a project. Then the planning activity becomes a prioritisation exercise from one big pool of risks and features, to meet the goals and objectives.

Some risks pose a threat, managing such threats helps avoiding vicious events in your project. Hazards for example cause recalls from the market as a very high cost in $ and reputation. Unmanaged scope creep has been the number 1 killer of projects for decades. Missing a business commitments can have impact on the business far beyond the project's problems.

Some risks however, pose an opportunity. When you proactively plan for utilising opportunities in your projects you create a momentum for Virtuous events.

Finding alternative suppliers could be a make or brake factor if on of your major suppliers cannot provide your components anymore. Patents review could save you vicious IP infringement, and create virtuous opportunity of new patents you file for your new ideas. If your budget allows it, you many need to move faster by managing different mitigation in parallel, and chose the best outcome asap.

Last word, I find processes and organised work a very helpful tool in managing risks. Say you have a continuous integration server, you create virtuous opportunities to minimise surprising defects when you least expect them. Or you have a traceability matrix on risks and features, to constantly avoid missing out, and also prioritise the burning next steps.

This sounds like lots of work to keep everything tidy; but it's like keeping your house tidy, or your body healthy; you can avoid the daily and weekly activities of maintenance and then when a problem arises a big operation is required to mitigate it. Or you choose to spend a small effort every day or week, and when a problem arises, and as you really need a solution urgently, you mitigate it gracefully.

NEXT STEPS:

Observe:

Outcomes perceived as of Good or Bad Luck events in your project, and what risks could be planned to manage them upfront?

Don’t:

Keep putting fires out, or waiting until it's too late! 

Do:

Learn how manage different risks, even a quick brainstorming session with your team is a great start;
then allow time in your plans and schedule to keep following up on them.

Interesting Read:

The Cost of Delay, by Henrico Dolfing

https://www.henricodolfing.com/2019/11/what-is-real-cost-of-delay-of-your-project