 |
|
 |
|
|
| Home | - | White Paper Index |
An Alternative to the Business Case |
First published July 04 |
Neville Turbit - Project Perfect |
Rating |
 |
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.
It will come as no surprise if I were to say that some numbers in Business Cases are rubbery. It would probably come as no surprise to say that many are downright lies. I worked for an organisation once that had an office in a street called Foveaux Street. We invented the "Foveaux Forecasting System". When asked for a projection of cost, volumes, growth, records, or even football scores, we would look out the window, read the number plate of the first car we sighted, and adjust the decimal point. If asked for a growth rate, and the first car passing was "ABC 123", we would estimate 12.3%. Sometimes I think business cases would benefit from this approach. |
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.
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?
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.
Here are a number of Business Cases that would never have passed the first review.
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."
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.
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.
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.
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.
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.
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.
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?
Rather than ask the ROI on a project, here are a few other questions to ask.
All these questions are not about undertaking a project because it has a two year payback period. They are about surviving.
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!
|
To date, 57 people have rated this article. The average rating is 4.30 - Add your rating. Just select a rating and click the button. No other information required. Only one rating per person is allowed. |
|
|||||||||||||||||||||||||||||||||||
