Share what you know with millions of people
Focus is the best place to turn what you know into remarkable content
0
How can ERP buyers write services contracts that link payment to performance?
Events
- Dos and Don'ts of Small Business Marketing May 29 @ 11 am PT
- Lead Nurturing 202: The Next Generation May 31 @ 11 am PT
- The Tricks to Paid Media June 6 @ 11 am PT
- Display Advertising for Brand Awareness June 20 @ 11 am PT
Related Activity
6 Answers
For me, this issue raises three questions:
1) What happens if the implementation services provider refuses to negotiate?
2) What terms would help drive successful ERP implementation?
3) Should the buyer bind itself to terms that incentivize its own performance?
With respect to #1, in many cases, it's not uncommon for implementation services providers to refuse to put their skin in the game. If the services provider won't negotiate, I would think about looking for a different implementation team. To me, a refusal to make payment contingent upon performance shows a lack of confidence in one's own ability to manage a successful project.
With respect to #2, I like Steve's idea, but I think the payment structure needs to be better allocated than 50% up front and 50% upon completion. First, many vendors will refuse this type of arrangement - particularly if the buyer is a small to medium sized business with relatively weak bargaining power. Second, it doesn't go far enough in terms of incentivizing specific behaviours and outcomes.
I recently negotiated a services contract for a mid-sized company (about $250million in annual revenues). We negotiated a deal where the client was required to put down 20% upon contract execution. The remaining four-fifths were allocated in equal shares, as follows: completion of core team training, completion of conference room pilot, completion of integrated pilot, and upon the productive use of the software.
By linking payment to these specific deliverables, the vendor was incentivized to ensure the effectiveness of: training, data migration, systems testing and systems performance in a live environment. For this client, these were the critical project success factors. For other clients, a different structure might be appropriate. It all depends on the particular circumstances of the project.
The last question, #3 is probably a tougher pill to swallow for most ERP buyers. Basically, they would be agreeing to some form of contractual handcuffs to incentivize their own performance. In theory, I think it's a great idea, because the buyer and its teams bear huge responsibility for ERP implementation success (it's not just the services provider). The question is whether they would be willing to bind themselves to drive their own performance.
This is a very interesting topic and there have been some interesting comments made – with a primary focus on the implementation and roll-out.
In my view, true performance-based contracts are based on some notion of shared risk between all parties, rewarded through shared returns from successful completion of the project. Whether the return is driven by a notion of savings or revenue upside, the vendor is paid a pre-determined share of the value target. Even if the target is some notion of customer satisfaction, this needs to be defined in terms of the financial impact of improved customer retention or cross product upsell.
For this to happen, there needs to be some work done as part of the initial selection process in determining how to agree on what are the return targets.
A strong business case must be prepared and include:
• A baseline for the target value metrics, such as current FTE cost per transaction, for change in value derivation resulting from a new system
• The direct linking of changes in value to functional areas of the new system that will result in efficiency and effectiveness improvements
• Enumerated materiality of risk to key value achievement, not just a list of risk factors
• Specific risk mitigation strategies
The business case then enables the:
• Continuous monitoring and re-evaluation of project performance against the original plan
• Value-based prioritization for proposed changes
• evaluation of defined metrics for determining actual benefit realization
In the absence of these business case elements, performance will be evaluated solely on duration and budget ─ in effect a penalty-based contract vs. a true performance based contract.
Typically ERP and SI vendors are incented to sell feature/functions (I used to work for an ERP vendor) and billable hours respectively. As to whether they would embrace pay for performance, I suspect that if enough customers started insisting on it then they would have to embrace it.
If you’d like to read more about how this can work, please visit http://www.exigenebit.com/approach/how-we-engage
Michael,
Great question. I've negotiated a number of contracts in my time and services are always a risky area. If I remember, you've identified that services can be 8 times license fees. The following is the track record of ERP projects:
•ERP projects that take longer than expected: 93 percent***
•ERP projects that exceed original budget expectations: 59 percent***
***2008 ERP Report
Panorama Consulting Group: Eric Kimberling
January 7th, 2009
http://www.panorama-consulting.com/whitepapers.html
http://it.toolbox.com/blogs/erp-roi/panorama-issues-2008-erp-report-29172
Services contracts that link payment to performance can be done quite simply: 50% of the payments up front...50% of the payment upon satifactory performance. The tricky part is clearly establishing what constitutes satisfactory performance. I would strongly recommend the budget and schedule be at the top of the list. Performance should also include those "users" that are actively using the application, the number of support calls/hours required to keep the users using and the financial metrics of the solution (increase productivity, accuracy, collaboration, margins and/or revenue).
These payment terms will do a couple of things. They will allow the customer to have control over the costs. They will incent the services provider to get their stuff done on time and under budget to the metrics established. Likely, the services vendor will break the project up into micro-projects that expedite the speed with which various departments are up and running. This gives the customer the opportunity to disrupt only a portion of the business at a time and limit the scope of the project to just that area (as much as possible). The vendor will be less likely to bring up tangential issues that tend to prolong an engagement. Not often will they admit that is their nature but it is...find more projects while they are getting paid for another.
I think that hell has frozen over or the 5/21 people were correct as I agree with many of the points that Steve raised.
Being on the ERP vendor side of the fence, one perspective that needs to be understood is that implementations should be a partnership between the company and the ERP implementation team.
For example, at the kick-off meeting of an implementation process, Expandable and the customer walk through and agree on a implementation plan. This plan lays out the tasks that will be performed and assigns one person who will be responsible for each task, as we have a belief that if more than one person owns the task, then potentially no one owns the task. In addition, all tasks have a date of expected completion.
If the task date milestones are met, then the implementation will be met on schedule. If however, there are delays in providing the chart of accounts, data that needs to be migrated or agreeing on the work-flow processes then chances are the "go-live" date will most likely slip through no fault of the implementation team.
To Jonathan's point " If the services provider won't negotiate, I would think about looking for a different implementation team", I would agree with the caveat that any delays or performance issues that trigger some sort of penalty on the implementation team, should clearly be the fault or the responsibility of the implementation team.
One more point. Obviously, the goal of the linking payment to performance is to have a successful and timely implementation. The best way to get comfort with the vendor's ability to deliver is to ask for references (my favorite answer to so many questions). If the vendor or implementation team has been successful in the past, there is reason to believe that they will be successful again.
One key is to ask for enough references so that you feel comfortable that there is enough depth in the references.
I think the idea of shared-success as posited by Stephen is a bad idea for the vendor. The vendor has no ability to actually get the customer to achieve the results. They can lead the horse to water but if the customer won't reduce the headcount as the gain share calls for...there go the rewards. If you take a gain share approach and equal risk is rewarded, then the vendor shouldn't be compensated until the results are achieved...which they can't achieve by themselves...so yeah....not a good model.
Answer This Question