The devil, as they say, is in the details. Don’t get tripped up on these common mistakes when calculating SaaS implementation costs.
If you are contemplating a digital transformation initiative that includes migrating to a SaaS solution, one of the key factors you’ll evaluate is the total cost. But don’t stop there. For a more accurate total cost estimate, you’ll want to break the costs down to the external costs of the annual contract value for the SaaS subscription and the one-time implementation costs.
Avoiding these common mistakes will help you better estimate SaaS implementation costs.
1. Reliance on a high-level range estimate from SaaS provider or system implementation (SI) partner
Your SaaS provider’s primary focus is on closing subscription deals. The last thing they want to do is scare off a customer with a potentially high implementation cost. The same concept applies to your systems integrator (SI) partner. They want to close the deal and begin the project as soon as possible.
Presenting an initial estimate on the high end may lead a customer to consider other partners or even cancel or delay a project. Additionally, the SI partners work closely with the SaaS providers and therefore, are cautious not to do anything that will put the SaaS provider’s deal in jeopardy. So, both of them may be motivated to present a low initial implementation cost estimate.
To keep these estimates low and avoid scaring off a customer, the estimate may be built around some unrealistic assumptions and/or omit the customer’s estimated level of effort. For example, it is common for an estimate to assume that the customer will be adopting best practices with only very minimal configuration work required. In other scenarios, an estimate may be built as more of an installation project with unrealistically low change management levels of effort.
This does not mean that the estimate is not accurate. It may very well be accurate for the defined scope and assumptions. The challenge for customers is determining if the defined scope and assumptions realistically reflect the full scope of work required to meet the customer’s transformational goals. For example, a common assumption is that the customer will make all decisions within a specified period of time, such as three business days. You need to be sure that such a short turnaround time for decision-making is reasonable and achievable.
2. Failure to properly define customer responsibilities and level of effort
As mentioned above, the implementation partner may omit the customer’s (your) expected level of effort and only identify the work that the partner will be performing on the project. Alternatively, the estimate may include only the portion of the customer work that is required for the implementation partner to complete. This may not include all of the work required to achieve your definition of a successful implementation.
Additionally, customers need to be careful not to assume that an estimate is precise. The estimate for your implementation partner’s work effort will include some sort of contingency to account for any estimate variance. You should also expect that the estimate for your level of effort will be even less precise since the implementation partner has little-to-no insight into estimating your capabilities and productivity levels.
But having a complete understanding of your expected level of effort is important so that you can properly staff the project. Commonly missed customer responsibilities include data cleansing, legacy system preparation, training delivery, and development of future state governance and support processes, just to name a few. If certain responsibilities are omitted or underestimated, then during the project you will have to find additional staffing resources or face a change order, either as a project delay to enable you more time to complete your work, or to offload some of those responsibilities to the implementation partner. Either way, this is a foreseeable risk that can and should be addressed as part of the estimating process and prior to using the estimate for budgeting and planning purposes.
3. Using a multiple of the subscription fees to estimate implementation costs
Many organizations fall into this trap, even if only to get a rough order of magnitude of the estimated implementation cost. The challenge with this method is twofold: First, the actual implementation cost is going to be based on the required level of effort to complete the project scope. The project scope is going to be dependent on the number and complexity of the required configurations, integrations, business process changes, etc. The implementation cost factors can vary greatly for the same SaaS bill of materials. Plus, this does not even take into consideration the customer’s internal level of effort and resource requirements.
Second, the better the negotiated price of the subscription, the higher the multiple will be for the implementation costs. The cost of the implementation is going to be what is required to achieve the customer’s project goals. The simple fact is that the implementation costs are not driven by the cost of the subscription deal. But the subscription costs present much more opportunity to be negotiated and discounting can vary widely between deals with similar bills of material and volumes. So, using prior project subscription costs and their associated implementation costs to derive some sort of formula for estimating implementation costs on your project is highly unlikely to be accurate and may actually vary substantially from your actual implementation costs.
4. Reliance on fixed fee estimates
Some organizations operate under the mistaken belief that a fixed fee, even an early estimated fixed fee with a stated variance range, means that there will not be any additional costs. What you need to keep in mind is that the fixed fee only applies to the implementation partner’s estimated level of effort for the defined scope and assumptions. The fixed fee is determined by conducting a time and materials estimate and then adding in some percentage uplift as a contingency to allow for estimate and performance errors. In some unique situations, fixed fees can be tied directly to the level of effort specifically identified or to just a duration of time with no commitment as to actual delivery and completion of the project. Regardless, any fixed fee is still subject to change orders for the following:
- Additive scope
- Assumptions that turn out to be false during implementation
- Customer’s failure to complete work responsibilities on time
- Customer’s failure to make decisions on time
- Late performance of any third-party work responsibilities
If you have transparency into the contingency percentage built into the fixed fee, this will provide you with an idea of how confident the implementation partner is in their estimate. As a rule of thumb, project overruns are typically spread evenly across three areas:
- Implementation partner performance
- Customer performance
- Additive scope
Therefore, if you know the contingency built into the fixed fee, you can multiply this number by 3 to get a more realistic contingency that you should build into your total project budget. Oftentimes this contingency percentage is much greater than you may normally build into other projects, but this is a much more accurate contingency to use for transformational initiatives.
The rewards of being realistic
It’s never fun to have to go back to your steering committee asking for additional funding above your project contingency amount. The best way to avoid this scenario is to make sure your implementation cost estimate is built on a realistic scope and assumptions, includes a complete customer level of effort, and has a realistic contingency built in that is reflective of transformation programs.
This article originally appeared on CIO.