Make your case with total cost of ownership

You’d like your department to adopt a new development platform, but no one is listening. You’d like some new project to be approved, but you don’t know how to push for it. What might help is taking a perspective that management will more readily appreciate. New technology costs money, but you may be able to show that over time, the change may not cost as much as the alternative it’s replacing. Do this by looking at the total cost of ownership (TCO).

Timing and money
Timing is an important factor for bringing in a new application development technology. While keeping a competitive edge is undoubtedly critical to long-term success, your company likely will wait to move forward until you can show them that doing so makes good fiscal sense. You need to be able to show that the new direction can have a positive impact on the company’s TCO.

The TCO is a calculation that includes all of the costs incurred in using technology and services, and it includes direct costs, like hardware, software, and employee resources, as well as indirect costs, such as training, maintenance, and other intangible costs.

Direct costs
The direct costs (the actual cost of purchasing equipment and services, for example) of using new development technology can vary greatly, especially when newer, faster, or more expensive hardware is required. When making your case, it helps to:

• Determine what constitutes “long term” and “short term” in the eyes of management and decide which one the company is known to focus on. Show how the direct-cost projections affect the time span most important to them.


• Start cautiously. You have a better chance for success if you implement the new technology on an application that is not mission critical.


• Keep it small. Divide the development project into phases. Reduce it to its simplest form for phase one. Let that success build on itself in phase two, three, or five. Project success comes down to making the budget and timelines and having the application function. Add gizmos and gadgets later.

Indirect costs
Indirect costs are somewhat harder to put a price tag on and include such things as lost productivity and downtime. These costs, however, are a vital component of controlling the TCO. Despite the perception that indirect cost savings are a hard sell to executive management, diligent attention to indirect costs can help reduce total cost, especially when the TCO model reflects the financial impact over the useful life of an installation, whether in-house or commercial-off-the-shelf applications (COTS). Let’s look at some ways you can reduce indirect costs on new projects.

In the code

• Design your applications the way you help design the project: Break it down into small, reusable segments.


• Start with the generic and then add parameterized, easily modifiable sections. This is especially useful if the application might be used externally, but it’s also sound advice for in-house applications where business needs change frequently.


• Fully define your use cases or user roles. This will reduce production maintenance. Peer support constitutes 47 percent of all indirect costs, the largest percentage, according to the recent Gartner report “CIO Update: the Impact of Indirect Costs on Total Cost of Ownership” (May 31, 2000).


• Document your code well. Take advantage of document management tools.


• Implement and follow coding standards. High turnover is endemic in the industry. You might be placed on a new project or win the lottery. Coding standards allow others to pick up where you left off.


• Know the standards, know when to break them, but most importantly, document how and why you broke them.


• Conduct peer code reviews. This encourages programmers to develop according to standards and allows for good knowledge transfer.

In projects

• Make sure project scope is well defined and thoroughly understood before throwing development-hour projections to the project manager. Many projects fail because arbitrary numbers become hard and fast measures of project success.


• Work with the project manager and the business-unit specialist to fully understand the business logic and be sure to ask the right business-unit specialists how the application can be reduced to its simplest form for phase one.

Training For yourself: Training budgets are sure to be tight if recent U.S. fiscal performance trends for tech companies continue. Although this means new technology training might be hard to come by, persistence pays off. It also helps to know management’s goals for technology and to be willing to move in that direction when requesting training. Roll up your sleeves, conduct the supporting research yourself, and have a sound justification prepared when you submit your request. For others: Make it easy for the production staff to support your in-house applications. The project budget should include knowledge transfer for the help desk/support staff. Good application-support documents for the IT staff, user guides that are clear and easy to access (preferably via the company intranet), and good code documentation can extend the useful life of an application. Causal learning and self-support cost $2,470 per user, according to the previously cited Gartner report.

Buy vs. build
The TCO is greatly affected by whether an application is purchased or built in-house. Developers can play an important role in helping determine which route to take. Here are some strategies for making this decision.

Testing COTS applications prior to implementation
When the question is whether to buy or build a mission-critical application, make sure you have enough time to fully evaluate the COTS application prior to making a decision to proceed. Install a test version just as you would for a full deployment of the tool, define the test scenario, and get commitment from the business unit to use the application long enough to learn its shortcomings. Use the full evaluation period of an application prior to making any purchase decisions. Make sure you understand the scope of customization required, if any, and ongoing support costs that make sense for your hours of business.

Next, compare your findings to a well-developed plan for an in-house custom application. The solution should materialize, based on the direct cost projections, the availability of resources, and the results of similar, previous application deployments.

When determining whether to buy or build an application, ask these questions:

• Does the application increase or decrease data complexity?


• Do we have full commitment of promised resources?


• Is there a record of having successfully built applications in the past?


• What costs will there be to interface with COTS software?


• Is installation and training support provided by the vendor? How much will that cost (including time away from the job)?

Summary
If you want to make a particular project happen or deploy some type of new technology, you will have to make a business case for it. A compelling factor that you should include is the TCO. Some of the costs are obvious, but others are not. Further, you can actually affect the TCO by implementing what amounts to some good programming practices. And finally, looking at the TCO when considering alternatives (such as make vs. buy) can produce results you might not even expect.