Making a business case for Web services
|A friend recently suggested I call a psychic hot line to find out when IT spending was going to pick up. He knew an industry analyst who had left the field for the greater job security and prestige of being a psychic advisor. She’d helped him find his cat and he was sure her IT predictions would be even more useful.|
Well, according to Madam Zoomba, the long-awaited increase in IT spending will happen near the end of 2003 or maybe in early 2004, unless of course things change. In that case, I’m free to come back and pay for a new prediction.
Whether spending picks up or not, one thing seems destined to remain the same -- business wants measurable benefits from IT projects.
The economy still poses a challenge to businesses. Every dollar of IT spending must count. There’s no room for buying technology for technology’s sake. Everyone is familiar with calculating a Return on Investment (ROI), which is the typical way people justify projects. All you need are estimated costs and benefits. What could be easier? Unfortunately, coming up with meaningful numbers for costs and benefits is a challenge.
But even if you have an ROI prediction, it is not enough to get a project funded in today’s economic climate. That’s because ROI doesn’t tell us much on its own. If you want to know the time frame for benefits, ROI won’t tell you that. It also won’t tell you if the business would do better investing in Treasury bills than in your project. Your business case must account for the time period of benefits, return rates the business needs for investments and the time value of money. Suddenly, you find yourself needing even more information for your business case.
Remember that making a business case is about value creation for the business. We want to show tangible benefits. One way to take into account all of the factors you must consider in a business case is to calculate the Net Present Value (NPV) of a project. NPV essentially asks if the present value of all the benefits you will receive from your project will be worth more than the investment. If it is, then it is worthwhile to do the project. If nothing else, NPV allows you to compare projects and to select the ones that deliver the most value to the business.
No matter what your project, you always need to estimate costs and benefits. Coming up with either one can be a challenge. I’ve had people hand me project proposals where the only cost was software and the benefits were almost infinite. But you need a much clearer picture of costs and benefits if you want your proposals accepted today. Determining software costs is an easy place to start: A salesperson gives you the list price. You say, “Not in today’s market!,” twist his arm and he comes back with a 25% discount. What could be simpler?
But there are additional questions you need to ask to uncover other standard costs. For example, where is the software going to run? Do you have existing hardware or will you have to buy more? Is there a cost to use it? Most software doesn’t install itself and become productive; there is a lot of work in implementing a system. This is just as true for Web services as it is for any other piece of infrastructure. Who will do the implementing? How long will it take? Once the software is running, how will you manage it? What happens if the server crashes? How will you restart the system and any jobs that were running on it? Have you documented this process? Operational management of a system adds to its start-up and ongoing costs. Finally, how will people learn to use it? Are you providing training? Where will the materials come from for this? These are the simple questions.
The implementation process can add complexity and cost when you consider related issues. In this case, you need to consider the implications of implementing Web services. For example, could you leave legacy systems alone or must you create new interfaces for them? If you create interfaces, do you want to duplicate what already exists? As the systems now work, you often perform convoluted manipulations to get the information you need. Wouldn’t it be easier to create a new integration layer that handles these manipulations and then makes the information available as a Web service? How does that affect performance? Because underlying integration issues already exist, should you implement Web services in conjunction with other EAI tools? You also need to consider which Web services technology to implement. Do you implement basic Web services? Would there be value (and cost) in implementing business process or security capabilities? Can you do all this in conjunction with another project that could help to cover costs?
Once you consider these questions, you will find project costs adding up. At this point, some people prefer to add a contingency, which may be done as a fixed percent of estimated costs. There are all sorts of good reasons for doing this. I’ve certainly done it myself. But when I first build a business case, I prefer not to adulterate my estimates and handle risk differently. We’ll look at that in a moment.
What benefits can you expect from the software? That depends on your software and its capabilities. Web services give us several potential benefits. For example, you might be able to increase revenue by offering new services to customers. You might also use Web services as a new channel for existing services. You would estimate this benefit as you would any product or service. For example, Web services-based business process modeling can make it easier and less costly to change business processes. They can provide simplified access to information and reduce the complexity of integrating disparate systems. In each case, you look for specific measurements of improvement. For example, I know of one company that used Web services to improve collaboration with its suppliers. They cut supplier cycle times by 50% and inventory by 25%, which added up to bottom-line savings of $2 million per year.
When you talk about benefits, claims of cost avoidance can be tricky. There are always questions about where the money went. Did you really save money? If so, what can you cut because of the savings? It’s a bit easier to show decreased costs. For example, you might reduce the cost of transactions by eliminating steps or manual intervention. Web services can lead to lower development costs and shorter delivery times. I know of one project that was estimated to cost $800,000, but was done for $30,000 with Web services. One key question to ask about any benefit: When does it occur and does it come all at once? You often need to determine benefits per time period.
There is one more piece of information you need before building your business case. You need to know what ROI the company requires. This figure is typically known as the Weighted Average Cost of Capital (WACC), and the CFO should have this number. Alternatively, your company may use another hurdle rate for projects.
By now, you have quite a bit of information for your business case. You know your costs, benefits, time period for benefits and hurdle rate. Are you done? Not quite. Before you crunch the numbers, you need to talk about risk. One way to handle risk, other than baking in contingency, is to adjust the required return. For example, if a project has the same risk as the operation of the business, just use the WACC as the rate. If the project is riskier, increase the rate.
You are finally ready to build your business case by calculating the NPV of your Web services project. Remember that NPV accounts for all of your factors. If it is positive, then the project is a good investment for the company. You can also compare project NPVs. Those with the highest NPV win because they deliver the most value to the business.
John D. Williams is a contributor to Application Development Trends. He is president of Blue Mountain Commerce, a Cary, N.C.-based consulting firm specializing in enterprise, domain and application architectures. He can be reached via e-mail at firstname.lastname@example.org.