Terryn Barill is an IT consultant in Princeton, NJ.
I have a question regarding the belief that when describing projects on which you’ve worked, you should always indicate what you saved the company. But how do you describe what you saved in terms of dollars if your job was developing applications based on spec?
Building a business case for nonrevenue projects is tricky; however, IT value itself is a complex subject. Most business people don’t think of IT in terms of value; they think only about the IT costs: IT budget, total cost of ownership (TCO), IT spending, and other concepts typically associated with IT.
To prove the value that a specific IT project gives the company, you have to look at items such as user productivity, revenue per employee, transaction cost reduction, cycle time improvements, and risk reduction. Not all these values will always have a clear dollar amount associated with them.
As an example, let’s look at documentation systems. To many IT workers, documentation is often considered an unimportant, last-minute task (which usually doesn’t get done at all). I’ve heard plenty of IT people say that doing documentation is a waste of money and time.
Although poorly written documentation is a waste, I think good documentation is valuable to the company, especially in regulated industries. It provides a clear map of a process, application, or IT system, useful for explaining things to auditors, new employees, or vendors.
A value list for specific IT documentation might look something like this:
- Provides protection from legal liability and noncompliance
- Creates standardization of process between company and vendors
- Allows for standardized training
- Encourages consistent application and minimizes rework
So how would you put numbers to these items? Anticipating the costs of legal liability is never easy, even if you limit it to potential fines and penalties. (If, however, your company is currently out of compliance, this may be a number you would wish to include.)
If, for the other items, your company uses a standard metric for employee hours in another measurement, such as for a cycle-time reduction goal, you might be able to give a ballpark estimate.
Another common technique to make a business case is to look beyond what an application does to what the company will not have to do once implementation is complete. Eliminating redundant software maintenance and upgrades, cutting integration costs, and negotiating bundled agreements with vendors can all have projected savings estimated. Your specific issue of spec proposals for applications would benefit from this approach.
For example, let’s say you’re going to develop a software application that will replace a three-year-old application. Someone in the business unit has already requested an upgrade for the old application. Your projected savings could look something like this:
- Elimination of current duplicate applications: $XXXX
- Elimination of proposed software upgrades: $XXXX
- Built-in integration with XX application: $XXXX
- Bundled managed services agreement w/vendor: $XXXX
Management may or may not decide to do all these items related to your application, but detailing them will help make the case that your application has value to the organization.
Another example is training applications or process changes that allow for faster or more streamlined training. You could make the business case per employee (or user) like this:
- Current cost of multiple training applications per employee: $XXXX
- Current cost of in-house/outsourced training per employee: $XXXX
- On-the-job training (estimated hours x avg $ per employee): $XXX
- Cost of developing new training application: $XXXX
- Elimination of x number of training programs: $XXXX
- Reduction in number of required hours of training per employee: $XXX
- Estimated reduction in number of OJT hours required: $XXX
Note that the last three items are negative numbers. Show not only what it will cost but estimates of what it will save, which reduces cost and improves the return on investment for the company.
Remember that IT isn’t a stand-alone department. If the implementation of your IT project will result in a business process improvement, fulfill a need for a business unit, or automate/re-automate a process, you can work with the affected business units to determine projected savings.
By including business value and process factors in your projected savings, including both what the application/hardware does and what it will allow the company to stop doing, as well as nondollar value returns such as hours saved in user productivity, transaction cost reduction, cycle time improvements, and risk reduction, you can make a successful business case.