- Getting to Business Value
- Developing a Model of Your Customer Relationship
- Setting Business Goals
- Setting Requirements: Who, Where, What, and Why
- Organizing and Publishing Project Documents
- Prioritizing Requirements
- When Requirements Should Bend
- Knowing Your Boundaries
- Making the Business Case
- Quantifying the Return
- Developing a Straw-Man Schedule
- Avoiding the Big Bang Project
- Outsourcing
- Setting Executive Expectations
- Getting the Right Resources Committed
This chapter is from the book
This chapter is from the book
This chapter is from the book
Making the Business Case
Most companies will require a formal business case for an investment in SFDC. Even if yours doesn’t have a formal review meeting for the decision, it’s a good idea to go through the exercise of cost, benefit, and ROI analysis so that the team understands the financial implications of what they are doing. Understanding the things that really make a big financial difference—and the things that really don’t—helps everyone make better decisions throughout the life of the project.
Estimating Costs
When evaluating Software as a Service (SaaS) systems such as Salesforce.com, it is tempting to think that cost analysis isn’t critical. After all, it’s just a monthly fee and you pay only as long as you’re receiving value... right? That’s what the salesperson wants you to think, if only to make you stop thinking. Life isn’t that simple.
Procurement
The big three cost areas are procurement, implementation, and ongoing user expenses. Procurement costs for SFDC, like most SaaS products, consist of a monthly fee. The fee varies based on the following factors:
- The number of users (internal “full feature” users, platform users, partner users, and customer users)
- The version you buy (most readers of this book will purchase Enterprise edition, but many will also want the Mobile edition, the sandbox, or other extra-cost items)
- The length of the contractual commitment (one year is the minimum; more than three years seems to make little difference to the discount)
- Your willingness to prepay (prepaying one year makes a difference, but longer prepays seem to make less of a difference)
Because you’re gong to be delivering the system in phases, make sure to activate only the number of seats you’ll actually use at any one time. In the negotiations for a large deal, this aspect of incremental deployment may save your company a significant sum.
Include add-on products in your procurement cost estimates, thinking through phasing effects that will affect the number of users and timing of activation for each product separately. Most add-on products for SFDC are also SaaS, but a few are on-premises products with hardware requirements and perpetual licenses. For those products, don’t forget to include the cost of hardware procurement.5
Do not neglect support fees. The basic support level that’s included in SaaS products will be insufficient for at least your first year. You’ll need speed of access to in-depth expertise that is available only through premium support. Your team members (particularly developers and system administrators) will also need technical training classes to become rapidly productive. Do not negotiate for these items piecemeal if you want the best discount.
If your company will have more than 100 users, the annual fees for SaaS can be a surprise. While it’s true that you aren’t paying for upgrades, patches, hardware, and operating staff, SaaS fees can easily exceed $100,000 per year, and the amount climbs to more than $1 million per year for the very largest deployments.6 Don’t assume that you’ll have a lot of bargaining power once the deal is signed: the only way you can get a better discount is to buy even more or to commit for an even longer period. Downgrades are not allowed. The vendor knows you don’t have a credible threat of changing the system, as the real cost of a changeover can be quite large even with the flexibility provided by SaaS’s Web services technology. As your users grow accustomed to features and your developers become experts at using SFDC’s APIs, you will be just as locked in to the vendor’s technology as you would be with any Microsoft product.
To get a significant discount on the procurement, you’ll need to get a budgetary allocation for the multi-year commitment. Work with your Finance department to develop the business case, making sure those personnel understand that the number of users will go up over time even if the per-seat price is stable.
Implementation
In contrast to “procurement costs,” implementation costs for SFDC and other SaaS products are one-time fees. You will almost certainly need consulting and other services required to convert legacy data, integrate with other systems, write custom APEX and VisualForce software, test the system, deploy it, and train users. Do not assume that your internal IT people are interested in SaaS projects or that they have the required skills and experience (but check out Chapter 13 anyway). Some of the implementation costs are easy to identify and are “fixed fee” in nature (e.g., training classes). Most of the big elements of implementation, however, are highly customized and can be brought to a fixed-price bid only after significant analysis by your vendor. Of course, every Finance department will want a fixed price, but there is significant gamesmanship in the bidding process. It is very easy to get caught up in the engineering change order (ECO) trap, where “fixed price” contracts create an avalanche of over-runs.
The first step in quantifying the implementation costs is drawing up the statement of work and development/integration requirements for each of the projects. The more homework you can do yourself, the more accurate the vendors’ bids will be. Some of the project areas will require analysis that you can’t do, and the bidding vendors will have to analyze this themselves. The vendors are unlikely to do enough “drill-down” analysis for free, but there’s good news: this scoping project will be short and should be fixed-price. This is money well spent before you make a large commitment. Some vendors will do this scoping project only after you have signed on with them for the main project. My own experience with this kind of vendor is not good, but don’t treat that issue as a show-stopper. If the vendor is very well qualified and you trust the consultant, proceed.
Note that the cost of implementation talent for serious SaaS projects isn’t that much different from the corresponding costs of conventional on-premises software packages. Skills and deep experience in SaaS implementations are fairly rare (particularly outside the United States), and fees can be $300/hour or more for the best people. Many customers have experienced overall implementation costs that exceed the software fees they pay to their SaaS vendors in the first year. Although this amount is significantly fewer dollars than customers paid for classic enterprise software (where implementation was typically projected to be 1.5 or more times the cost of the software licenses), it may still come as an unpleasant surprise if proper allocation for it has not been arranged.
Do your cost estimates only for the initial implementation, but know that the happier your users are, the more likely they will be to ask management for further system enhancements. It is not uncommon for companies to have multiyear engagements before they reach the management nirvana of the 360-degree view of the customer.7
Don’t forget the costs of your internal people. It’s not unusual to have five people be involved on a full-time basis in an SFDC implementation (even with consultants), with another five involved intermittently. Even though these people’s salaries are already budgeted for, the effort they put into SFDC will be time that won’t be available for other company priorities.
Ongoing Costs
After estimating total first-year costs—first-year fees, add-on procurements, and implementation expenses—the ongoing costs for SaaS basically consist of the annual subscription fees. There may be some one-time costs in the out-years (such as a data recovery exercise or temporary use of SFDC’s sandbox), so put a placeholder in those budgets. The more interesting ongoing costs are related to people: follow-on implementation or expansion work, training costs for new users or administrators, travel and fees for power users attending technical conferences (a good investment), and time for any consultants working on the system.
As with any large system, data pollution is an inevitability and is poisonous to the system’s credibility. Business analysts and others will discover corrupted or duplicate data creeping into the system over time. Whether it’s a temporary coder, a data-entry clerk, or overtime hours of internal people, some corner of the budget should be set aside for a health check and cleanup session at least once a year. You’ll almost certainly want a deduping or data cleansing tool, which will cost at least $3,000 per year, which is money well spent (see Chapter 7 for discussion of this). Furthermore, identifying the source of the problem, rectifying it, and cleaning up the data are often tasks carried out in collaboration with contractors.
These ongoing costs are likely to be most pronounced in year two of the system, but some budget should be set aside every year after the initial deployment.