BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles 10 tips on how to prevent business value risk

10 tips on how to prevent business value risk

"Would you tell me, please, which way I ought to go from here?"

"That depends a good deal on where you want to get to," said the Cat.

"I don’t much care where--" said Alice.

"Then it doesn’t matter which way you go," said the Cat.

“Alice in Wonderland” – The Reverend Dodgson, Mathematician, Oxford University

Business value failure risk is when the project runs the risk of not delivering the desired business value and has two underlying causes: uncertain valuation and communication issues. This article contains 10 tips on how to avoid these.

The Business Investor’s perspective is the only one that matters when considering risk management on IT projects. All other perspectives are subservient to those of the investor. From the business investor’s perspective, there are three categories of risk [1].

  1. Delivery Risk. The risk that the software is NOT delivered on time, on budget, and to the required quality.
  2. Business Value Failure Risk. The risk that the project does not deliver the value expected.
  3. Existing Business Model Risk. The risk that the project actually damages the existing organisation.

This article is the second in a series of three. This article covers business value failure risk and follows our first article on the risk of damaging the existing business model.

There are only four reasons for doing a project from an investor’s perspective:

  • Increase revenue
  • Protect revenue
  • Reduce cost
  • Avoid cost

All of these are expressions of business value. If the goal of your project is not a variation of one of these four themes, the goal is not expressed as a business value. Andy Pols and Chris Matts are very clear about this in their article.

Business value failure risk is when the project runs the risk of not delivering the desired business value and can be broken down into the following risks (in two categories).

  1. Uncertain valuation
    • a. The project has no value.
    • b. The value for the project is unknown.
    • c. The project does not deliver the value it expected.
  2. Communication issues
    • a. The project delivers the wrong value.
    • b. The business investor is not engaged in the investment process.

1. Uncertain valuation

The first and probably most common risk on IT projects is that the value the project is delivering is not known to those who should know and understand it. In order for a project to deliver the right thing the business reason for the project needs to be known and clear. All too often this is not the case. We see three reasons why this uncertainty occurs:

  • The project has no value
  • The value for the project is unknown
  • The project doesn’t deliver the value it expected

The project has no value

Many projects start without having a real business case that delivers value. Sure they will say they have a business case of course. And these business cases sound good, but do they actually deliver value? Most often not. Here are some examples of good sounding business cases that fail to deliver value. See if you can spot the problem in each of these (answers at the bottom of the post):

  1. “This project facilitates straight through processing and automation.”
  2. This project will support our goal of being number one in the target market.”
  3. “Mr. Big wants to have a mobile application.”
  4. “We need a strategic trade capture system for widgets.”

The value for the project is unknown

This risk is very similar risk to the previous. In this case there might be a legitimate business value for doing a project. However, no one on the project knows why this reason of why this project is being done.

The project does not deliver the value it expected

This risk occurs when a project is set up to deliver massive value, but fails to deliver miserably. It turns out that estimates of business value received are even worse than estimates of effort to produce something. And we know how bad we are at estimating our own efforts.

Many years ago I worked on a project where the business expert calculated that the profit to be made was X hundred million Euros. The team estimated that the cost of setting up the IT systems for the department would be 5 million Euros (I had doubled the real estimate). The project generated much excitement at all levels of the organisation. When it finally went live, the revenue was less than one million Euros. The revenue was more than one hundred times less than the expected profit.

Although real option thinking helps in this aspect to incrementally invest in building new capabilities, a more valuable set of information can be found in the Lean Startup community. The Lean Startup community lead by Eric Ries changes the emphasis from development to information discovery in the product development space.

How to avoid these valuation risks:

  1. Know what the business value is
  2. If the value is not known, stop the project till somebody knows the business value of it
  3. Use the “Hunt the value” process from Feature Injection to find the business value. This process allows the project team to find the value guided by the principle that all value is in the outcomes/output of the system.
  4. Look at the Lean startup community by Eric Ries for more information

2. Communication issues

The project delivers the wrong value

This risk occurs when teams work on a project without properly understanding the business value. Although this is similar to some of the previous risks, the difference here is that the teams faced with this uncertainty invent a business case and deliver against that made up business case. This business case is often not explicitly stated and so there is no way for the investor to know that the project team has properly understood why the project has been funded until it is too late.

Most people are familiar with “increase revenue” and “reduce cost” as a reason for investing in a project. They are less familiar with “protect revenue”. If a team believes their project should increase revenue where from an investor’s perspective protecting revenue is sufficient, the team will distort the requirements until they increase revenue rather than protect revenue. An example of this behaviour is when a competitor releases a new feature. The implementation to retain current customers may be quite simple, to make it a selling point for the system requires a lot more effort. This effort from an investor’s perspective is wasted.

The business investor is not engaged in the investment process

The business investor is rarely a single person in an enterprise organisation. The reality is that the business investor is a group consisting of all the major operational areas, namely Management, Sales, Operations, Finance and IT. The details will change from organisation to organisation.

A significant risk is that IT has unilateral discussion with each business department. IT is then forced to deliver on all commitments and ends up performing the business prioritisation process by themselves. This prevents the business from performing the prioritisation in the way that they would want as a group.

The key is that all groups are represented in the business investment process.

A reason that the business investors do not engage is because IT make the investment decision process so painful. They might subject the business to an hour long planning meeting each month. To ensure that the business are engaged it is better to ensure that the prioritisation takes place frequently and that it only takes a very short period of time.

How to avoid these communication risks

  1. Communicate, communicate, communicate
  2. Understand the four potential reasons for doing a project:
    • a. Increase revenue
    • b. Reduce cost
    • c. Protect revenue
    • d. Prevent cost
  3. Articulate the business value clearly to the project team, at a minimum to the core decision makers.
  4. Continually provide feedback to the business investor to ensure the project and the goals are still aligned.
  5. Have the business investors prioritize based on the why and not the what. So no more prioritising features, but rather business value.
  6. Prioritize frequently and within a very short period of time to keep business investors engaged

Parting thought

During the Napoleonic Wars, Englishmen were vigilant for French spies. A French ship was wrecked near Hartlepool, a coastal town in the north of England. A monkey dressed in a French uniform was washed ashore. The people of Hartlepool questioned the monkey. Because they couldn’t understand him they assumed he was a French spy and hung it as a French spy.

If you don’t know what value is, like the people of Hartlepool you may deliver something other than required.

The answers:

  1. The business case describes a solution rather than a value to be achieved
  2. The project delivers a strategic goal which does not (necessarily) deliver value
  3. This is an “ego app”. Good for Mr. Big to look good, but not delivering value to the company
  4. The business investor asks for a feature rather than articulate the value

About the Authors

Chris Matts is a business analyst and project manager who builds trading and risk management systems for investment banks. His aproach to IT risk management is based on what he has learnt from investment banking risk management. Chris tweets at @papachrismatts. He blogs here and here.

 

 

Olav Maassen works at Xebia as an agile consultant. He is interested in new developments and new ideas that can help others improve themselves. He knows how to inspire people to optimize their capacities and skills so that they can get the best results for both themselves and the company. Olav tweets at @olavmaassen.

 

 

[1] “Everything you know about IT Risk Management is wrong” by Steve Freeman & Chris Matts. Agile Times Volume 5 - The article gives famous examples of organisations that have suffered from all three types of risk.

Rate this Article

Adoption
Style

BT