Getting management to accept the up-front purchase costs as well as ongoing support charges of a software purchase can be impossible without the right justification.
How do you get management to approve a software purchase? Such approval is becoming next to impossible for many end-users. The reasons for this are many. For example, purchasing departments suffer a bombardment of solicitations for "solutions" to software problems they don't have or don't think they have.
One barrier you may need to overcome is the misperception among many managers that if people in certain functions know how to do their jobs they don't need specialized software. Such functions include bidding, estimating, circuit analysis, electrical distribution design, permit application, and project management. All of these functions can benefit enormously from the proper application of software. The challenge is convincing your management there is a problem and that the new software will solve it. As with any purchase, this one must satisfy a need.
What's the point? To justify a purchase, you must define the goal of buying this software. Normally, the goal is to solve a problem or increase efficiency. What problem are you trying to solve? What benefits are you trying to gain? What are your competitors doing with software that you are not able to do? How will the software improve efficiency? Why is there an efficiency problem now? Will this software fix it?
Whether you are replacing a manual system or upgrading existing software, you'll have certain objectives to fold into an overall goal. Simply needing an upgrade is not justification for a purchase. If you aren't making a significant improvement, you can't justify the expense.
Meeting business needs. If you cannot make a business case for the software, an upgrade isn't going to fly with your management either. Even if you make a business case for the software, that case must mesh with other plans you may not know about. For example, one company had a paper-based expense reporting system. Many people urged upper management to buy specialized software to replace the manual system. Others encouraged them to invest in custom programming and do the expense reporting in common office software. Still others wanted to run an online expense report system in SQL Server, which would require custom programming and expertise they didn't have. All of these people had strong business cases for their suggested solutions to the paper-based problem. However, upper managers chose none of these solutions. Were they just hardheaded? No, instead they chose an Application Service Provider (ASP). The ASP provides them with the software, secure server and storage, interface with American Express, and expertise specific to their industry and the types of expenses they incur.
What the managers did not do was assume the options presented to them were the only ones. They used the descriptions of those options as a starting point for shopping around. While awaiting a change and still suffering through the paper-based system, the employees who made the suggestions felt frustrated. They didn't know the company was negotiating a deal with a third party, because the company was not in a position to announce its plans. Had the company approved an interim expense reporting system, the resulting cost and confusion would have been hard to explain to investors.
Before you put too much effort into getting software approval, determine if your goal is in line with your company's immediate and short-term goals. In traditional capital purchases, we focus on long-term goals. With software purchases, you need to focus on near-term goals with an eye to expandability and future needs.
Determine exactly what the software's benefits are - in terms of the bigger picture and what is important to management. Will this software cut 10% off the price of a project? Will it improve the accuracy of invoicing, reduce accounts receivable time, improve the accuracy of bids, reduce employee turnover, or have some other impact on basic business processes?
Resolve resource restrictions. New software often requires new hardware on which to run. But, don't assume that because you have new computers you will have no resource problems. Resolve all resource questions - not just the obvious ones. Look at lifetime costs, training needs, and vendor support. Consider the cost of future upgrades. If the program uses a third-party database, consider the time and money involved in getting regular updates.
What if your database or archives from this software will contain sensitive information, such as social security numbers, proprietary design information, restricted phone numbers, or security access codes to customer sites? Will you have adequate security measures to safeguard this information? If not, your upper managers may decide to outsource the functions you want to buy software for.
Your purchase request. A software purchase request can be an expense item or a capital item, depending on how your company classifies software purchases and the amount of the purchase. In the old days, when you were asking for software to run on one or two computers, a verbal request was often sufficient. Today, a typical purchase is for a multi-user site license or enterprise license. It's a big investment of both time and money. Most software today ties into the "enterprise level" of a business, so its purchase is an enterprise decision. You also must consider how the software interacts with other programs, and if that will require upgrades to your existing software base. For example, how do your accounting, bidding, technical drawing, and project management software interact with each other and with your operating system, databases, user files, network, and various software utilities? A good software vendor can answer these questions for you. If you have the answers, you gain major points in the game of approval.
To add beef to your request, include a SWOT analysis as an attachment. In a SWOT analysis, you describe the strengths, weaknesses, opportunities, and threats likely to result from each option. Follow that with a cost-benefit analysis - your accounting department can help you with this. Before submitting a formal request, ask your boss or some other qualified person to review your request and discuss the software options with you. This will help you identify weaknesses in what you've prepared so far.
Consider the readability of your request. Keep it concise, so people won't find it intimidating or boring. Eliminate judgment statements about how the software is great, and focus on the benefits. Use hard data and case histories to justify any cost-savings assumptions you make, or you will lose credibility. Prepare an executive summary about a half-page long, so the "bottom-line" types can quickly see what they need to know.
Most of all, take the extra time to do your homework on the pertinent questions. Evidence of your diligence raises confidence in your ability to identify a good software purchase. If you find it hard to come up with hard data on the software, ask the vendor to put you in touch with current users. Once you have decided on a particular package, arrange for the vendor to give a demonstration to one or more of your company's decision-makers.
Don't make it a dog-and-pony show of stepping through the menus. Instead, focus on how key features provide benefits important to those who will be witnessing - or, preferably, participating in - the demo.
Sidebar: Objectives of a Software Purchase
- Reduce duplication of effort, through central database
- Reduce labor costs through automation, templates, and reusable elements
- Increase accuracy through forms and controls
- Increase efficiency through improved interfaces
- Increase quality through standardization
- Decrease costs through elimination of paper processing and storage
- Increase responsiveness through "real time" access
- Increase usability by making documents searchable
- Increase teamwork through collaboration tools
- Increase output because newer program is more stable than its predecessor
