Author: Neville Turbit

Overview

It is generally accepted that a new project requires a business case to get approval to proceed. The business case is a financial estimate, and justification for the existence of the project. So is it always the best way to agree a project should proceed? This white paper examines an alternative way of thinking. It focuses on two non business case reasons – Innovation and Survival.

Accuracy of the Business Case

If the business case is so inaccurate, should we be putting so much emphasis on inventing numbers that are baseless? Should we be doing calculations on assumptions that are so vague as to be meaningless? Perhaps ROI (Return on Investment) is not the right criteria in all cases.

The Big Picture

An organisation usually has some goals, or a corporate vision. Usually it is somewhat vague. It is not about quantification but more about direction. It is not about statistical measures but more about what the management wants the company to be. It is about creating initiatives that contribute towards the direction of the company. Should projects be approved for the same reasons?

Should there be a justification to move forward because it is contributing towards an initiative in an unquantifiable way?

Reputation for Innovation

I was recently talking with the CEO of a significant international IT organisation. She told me that she approved a number of internal projects each year that did not have a justifiable return on investment. One of her reasons was that she wanted to employ the best and brightest in her organisation. In order to do this, she needed to provide a creative challenge for them. She needed to stimulate them to use ground breaking technology.

As she said, perhaps one out of three projects delivered a financial benefit to the organisation. The other two were either abandoned, or at best broke even. The real benefit came from what the people learned, and were able to apply to other projects. It came from retaining the services of bright people who were able to do a better job then more middle of the road workers. It came from having people motivated and productive.

Her organisation was an early leader in Java. When .NET it started to catch on, it was ahead of the market. The new business it generated more than paid for the few failed projects. The premium people were prepared to pay to implement these technologies, funded the experimentation.

Business Cases that would Fail

Here are a number of Business Cases that would never have passed the first review.

• Art Fry who worked for 3M came up with sticky paper notes. The idea never made it past the first review. How could you justify the potential of Post It notes? Where was the business case? He used a great approach. He made a batch and passed them out to all the secretaries. When the notes ran out, and the secretaries demanded more, he told them to talk with their bosses. It would be a brave boss who told his secretary that there was no future in Post It notes and she couldn’t have any more.
• How solid was the business case for Michael Dell when he wanted to bypass the accepted supply chain and go direct to consumers. Furthermore, he wanted people to pay for a PC before it was built.

Neither of these would ever get up as a business case however they still worked. The underlying assumptions are just too fantastic to be treated seriously.

Robert D. Shelton, Vice President with the former Arthur D. Little consulting firm includes the ROI question in his symptoms of an anaemic internal market for creativity and innovation. He says that organizations that use only capital-return tools such as ROI or discounted cash flow tend to have a week innovation culture. “Moreover,” he states, “Appropriate measures don’t exist to evaluate creativity or potential projects in which there is uncertainty or ambiguity.”

Projects for Innovation

Perhaps the answer is that the organisation should take a venture capitol approach to some projects each year. If we were investing our personal funds, we might take most of our investments with a guarantee of stable returns, and a few risky investments with the potential for big returns.

An organisation is no different. If the organisation wants stability, they can focus on projects with guaranteed benefits. Avoid any risky projects. They will probably grow with the market, but not gain much advantage. If they want to outgrow the market, part of their project portfolio needs to be in the risky area.

A venture capitalist will invest in a number of companies knowing that the few wins will outweigh the failures. A company that wants to use IT to advantage needs to fund a number of risky projects. That is the only way they will get ahead of their competitors.

Diversify the Risk

Putting all your eggs in one basket is likely to mean you end up with scrambled eggs. It is better to diversify the risky projects and take a different approach to justification. For example, your technology people may propose a project to develop a program that can be integrated with a browser on a client’s desktop to advise them of price changes for your products. There is nothing available off the shelf that will do this. The way to start is to fund a proof of concept on a small scale. If it succeeds, perhaps you fund a trial in one region. With that experience, a business case becomes a possibility.

If you adopt this approach, you may find you can fund a number of initiatives that prove the concept before considering the business case. If the organisation invests a proportion of the IT budget in seeking out competitive advantage, perhaps they will find it. If they invest nothing, they can be assured they will not find innovative ways to use IT. It becomes a commodity.

Most organisations invest in market testing new products and services. Why not new IT services? The company accepts that a few marketing concepts will fail, but they need to develop a number in order to find a winner. So with IT. Some concepts will fail, and that is all right. The ones that succeed will make the exercise worthwhile.

Case Study

I spoke with a shipping company some time ago. In their niche market, all the competitors were running the same freight management package with minor variations. Although it could not be cost justified, this company had built their own system over the years which allowed customers to more easily process freight through Customs. This was the main competitive advantage for their organisation. Their growth was almost completely attributed to a computer program.

There had been no business case to develop the system. It had grown over many years but the IT Manager had some bright people and he encouraged them to come to him with development ideas. The company had a culture of innovation and encouraged him to experiment.

He had a budget to fund the ideas without having to go through formal approvals. Sure they had some failures and he had to write off a few projects. The successes more than compensated for the failures yet he said none would ever have seen the light of day if they had to withstand a rigorous business case evaluation.

Stifling Innovation in IT

Some of the brightest people I have ever met have been in the IT industry. Unfortunately, very few work for corporations. They tend to be out there creating games or doing clever stuff on the Web. The corporate IT area typically imposes a straight jacket which limits the bounds of innovation.

If you implement suggestions for innovative IT solutions, you will tap into the problem solving psyche that usually exists in an IT person. I had one situation where we identified an 18 month project to build a new system to handle investment products. The existing system was corrupting data and current values had to be manually calculated. We couldn’t even send out statements.

I had a systems analyst who was a handful to manage. He was always going outside the bounds of his role and often creating a great solution to the wrong problem. He came to me and said he could put together a temporary solution using an obscure programming language he had discovered. It would verify if the data was corrupt or not, and if not, calculate the current value. There was no guarantee of success. It defied all the architectural standards. The cost was unable to be calculated. In fact a business case was not even a remote possibility.

In spite of the corporate guidelines, I believed if it could be done, this guy could do it. We gave him the go ahead and put a budget together to cover his cost for 3 months.

He worked day and night. On occasions he had to be escorted from the building because he was almost asleep at his desk. Suddenly he had a pet project which was using his skills to the full. In 3 months he built the system. For the balance of the conversion project, we were able to supply about half the policies current values from the interim system, and identify where the corrupt data was on the other half.

The cost and time savings to administration staff were enormous. An innovative approach allowed us to overcome a major corporate obstacle and in the end there was an ROI. It could have failed but the upside of the project far outweighed the downside. IT Innovation triumphed.

Without a Business Case

There are already exceptions to the mandatory business case process. Some projects are driven by legislation (think Basil II in the banking industry). There may be no financial return, but they just have to be done.

Others are driven by keeping up with the competitors. It is not so much that the project will provide a competitive and financial advantage. It is more that it will keep you in the game. Don’t implement the change, and you will be out of business.

Postponing Major Upgrades

A company reluctantly accepts that they need to devote part of their IT budget to mandatory projects. Whilst some are driven by legislation, others may be driven by lack of support for older systems, network upgrades, new premises, expansion or contractions of their operation. Unfortunately, the usual name of the game is “Postponing the Inevitable”. Everyone knows it is coming one day but you keep putting it off. My advice is to forget the business case. Just do it.

Risk of focusing on the Business Case

Looking at the situation from a corporate perspective, what is the cost to the organisation of delaying? What is the cost of running an old and inefficient system rather than replacing it three years earlier with a newer system? What opportunities are lost? What is the drain of staff supporting an old system? If you loose key staff due to the view that their skills are not being upgraded, how will that impact a conversion?

The Questions to Ask

Rather than ask the ROI on a project, here are a few other questions to ask.

• At our present rate of rolling out new IT, where will we be in 5 years time? What will be the cost of catching up? Can we fund it in one lump sum?
• Are we providing enough new technology experience to our staff to keep them interested, educated and motivated? Are we happy with high staff turnover?
• How well can we answer questions about new technology if we don’t use it? Do we have the experience to make the best decisions for our company’s IT development?
• From our competitor’s point of view, what will they do to pass us in their IT services?
• If I was a competitor, and had to focus on IT as a competitive tool, how would I put us out of business?
• What new technology might eventually put us out of business if we don’t implement it?
• What IT services will we need to provide in the future, and how will we get the experience to provide those services?
• If we do upgrade some time in the future, can we guarantee the key staff who have the business knowledge will still be around?
• Can we see a window of time in the future where we can focus an area of the company on upgrading the system, or is now as good a time as any?

All these questions are not about undertaking a project because it has a two year payback period. They are about surviving.

Summary

It is a fact of life that most projects are approved based on a business case. This is probably the most sensible approach for the bulk of projects as long as someone is held responsible for achieving the benefits. On the other hand, if an organisation is innovative, they should look to running some projects without a business case.

Mix the portfolio with a few risky ventures that may allow the organisation to leap ahead of your competitors. Treat it as new product development. You might end up with a Post It note or you might end up with a flop. If you don’t try, you will end up with nothing. ROI is not a good measure for innovation. Fund innovation separately.

When it comes to IT contributing to the survival of the organisation, it is not about how little you can spend today. NASA tried that and it didn’t work. It is about keeping up with the opposition so they can’t use IT to put you out of business. It is about using survival as a lever to leapfrog the opposition. It is about not delaying work because now is not a good time. Will tomorrow be any better?

Always judging projects by their business case is for the prudent. Taking a decision that is innovative is for the bold. What sort of organisation do you want to work for

References:

Thanks to an article by Joyce Wycoff who is a co-founder of the InnovationNetwork, an organization focused on helping organizations develop a core competency of innovation. She has a broad background in management and marketing and a deep understanding organizational innovation. Joyce is the author of several books on innovation and creativity, including Mindmapping, Transformation Thinking, and To Do . Doing . Done!

Copyright Project Perfect