Reducing Financial Risk In Complex Product Development

How much will it cost and when will I get it?

Excerpt from Agile Executive overview, Certified Scrum Master and Certified Scrum Product Owner training by Innovel.

Anyone who has done significant project or product development work has heard the questions “How much will it cost? When will I get it?”

We have probably asked these same questions of others. When we buy a car or other manufactured product these are reasonable questions. A manufactured product has been designed, the manufacturing facility setup, the parts suppliers found, and the process for creating the product defined and tested. Manufacturing the product is a series of many steps. Shipping the product is also a series of defined steps. Even customizing the product (for example: colour, accessories) is a series of limited choices that are also well defined. We refer to this as a complicated problem. While there may be many steps and it is possible for things to go wrong, the steps and what to do are clear.

Let’s say we want a new system for determining which movie to recommend to you based on your previous movie selections. How do you personally decide what movie to watch next? The actors? The genre? The length? Reviews by others who have similar tastes to yours? Movie critic reviews? What your viewing partner likes? What your mood is? What time of day it is? The rating of the movie (PG, R, Adult, Family)? This is a complex problem. There is no clear series of steps to follow to solve this problem that will work every time.

At the beginning, we simply don’t know what the final product will look like or how it will perform. In dealing with complex problems the questions “How much will it cost? When will I get it?” cannot be answered with any certainty. When do customers and stakeholders start asking “How much will it cost? When will I get it?” At the beginning of the project or product, of course! The customer wants to know.

Well, to answer those two questions, do we know:

1. The people who will do the work? 
2. Do we know what technology to use? Do we know if it will work?
3. Do we know all the details of what to do, all the steps?
4. Do we know the roadblocks and obstacles we will face?
5. Do we know how long it will take for us to develop the solution?
6. Do we know what stakeholders (users, sponsors, etc) will think of our solution?
7. Do we know what problems we will need to solve?
8. Etcetera.

We are the most ignorant at the beginning of building a new system or product.

Yet this is the time we make promises, assign delivery timelines, sign contracts, fix deliverables, etc. Why do we do this? Because our customer asked us. Why does our customer ask us? What are the underlying reasons or root cause? Sometimes it is that the customer simply doesn’t understand that building a complex system is nothing even remotely like buying a car. But mostly the root cause is fear and uncertainty. The customer wants certainty when in reality there is very little that is certain. So we make a bunch of wild ass guesses and give it to the customer in a nice presentation, and they feel better, they feel more certain. But are we really? No. All the unknowns are still with us. We are still just as ignorant about the real future after we made the estimates, assumptions and risks as we were beforehand.

You don’t know what you don’t know.

This is not risk that can be quantified like your insurance company calculates risk on your car insurance policy. These are unknown unknowns. In 2019 most everyone thought work was done at the office, inflation was under control and that shutting down international travel across the world was impossible. In 2020 COVID happened and many impossible things suddenly became reality. That was an unknown unknown.

A reasonable solution to this problem involves addressing the root cause, fear.

Fear arises because people feel there is a lot at stake in terms of money and resources, and they can’t be certain about whether the system will succeed or not at the beginning.

In Agile and Scrum we reduce risk by:

• reducing our exposure to large costly decisions
• not betting the farm at the beginning on a particular plan or potential solution

Instead we approach product development as a continuous series of small increments, and at the end of each increment we inspect the completed work done. This allows us to really understand what has been completed, and also adjust our plans and trajectory as we learn more.

One significant advantage software products have over physical products is they can be used even if they are not done.

Think about Microsoft Word. How many of its features do you use? Which ones are most important to you? If you did not have the “mail merge” feature for printing envelopes would you care? If we can agree that some features are far more important than others, then why not:

• build the most important ones first
• see how they work
• start using them and carry on building the others
• change our mind and build other stuff we just realized was more important?

This not only lowers risk, it accelerates return on investment, since the product can ship earlier and start generating customer feedback, validating the market and generating revenue.

New product development is not “plan and execute”. New product development is a search. Searching is an inherently iterative process.

So, by approaching complex systems development as an ongoing series of small investments, we reduce risk, which in turn reduces fear. The psychological change we need to make with stakeholders is to shift their focus from “When will all of it be done?” to “What are we doing next?” and from “How much will it all cost?” to “What will we spend to get the next piece that we can use?”

This change in the mindset of stakeholders only really happens when they see that the team delivers valuable increments of the product in a regular and repeatable way.

I have worked with many stakeholders who have made this shift in mindset. It usually takes about 3 to 6 months working with teams doing Scrum to see the mindset shift, with stakeholders participating in the process. This shift to an Agile mindset can also have health benefits for stakeholders, since the reduced risk is real, they feel it and become less stressed.

Better return on investment yields less risk and less stress – benefits everyone can appreciate. Contact us if you would like to discuss how to reduce your financial risk.