PSA

Shortlisted News & Views

News & Views | Contract Negotiations

News & Views is published monthly by 180 Systems. Our objective is to provide recent articles to our readers on business technology topics. In some cases, our blog contains a title with a hyperlink to a source article, a quote from the article and our comments. In other cases, we have provided a blog without a hyperlink for original content by 180 Systems. We encourage you to post your own comments. You can also access our blog by topic.

You naturally want to minimize risks and avoid cost overruns before signing a long-term contract for a new ERP system. Your prospective vendor also wants to minimize risk, but is usually not in a position to do anything other than give an implementation estimate based on lots of assumptions about scope, roles and responsibilities. These assumptions could be fairly accurate, but could also be way off, which could lead to surprises and costly change orders during the implementation. Neither you nor the vendor want this to happen. Wrong assumptions that lead to change orders will create frustration, friction and could lead to you being an unhappy, non-referenceable client, or even worse, one who wants to abandon the project.

Everyone would prefer to avoid this. So we encourage you to consider a pre-contract Business Needs Analysis (“BNA”). A BNA provides the vendor with more detailed information about your environment that it can use to firm up its understanding and provide a fixed fee for the implementation. In the absence of a BNA, this work would normally be done by the vendor during the implementation, after the contract is signed.

The more analysis done in the BNA, the lower the risk. 180 Systems’ approach to the BNA is to identify the requirements that are the most challenging and/or unique and make sure they are clearly understood by the vendors so they can figure out how to handle them in detail before the contract is finalized. Although the vendors charge for their time to complete the BNA process, it is time they would be charging during the implementation anyway, and by doing the work upfront, the risky parts of the implementation can be built into the implementation contract and therefore reduce the likelihood of surprises.

A BNA should include

Implementation scope linked to requirements in the RFP

Conceptual design with agreed upon design decisions

Functional specifications for any requirement requiring customization

Statement of Work

The vendors may resist as they would rather just close the deal or are reluctant to assign resources to a client that may not sign a long-term contract. But if the risks are high, both the vendor and the client are protected using the BNA approach.

Statement of Work (SOW) Stoppers

The SOW is a key document from your vendor that can make or break the implementation. The vendors will do their best to reduce their risk by limiting scope to a high level list, assuming that you will follow best practices, and making a lot of other assumptions about you doing work that you don’t know or understand the effort to complete.

As the vendor risks go down, the customer risks go up. We recommend the following:

Scope is tied to the requirements in the RFP which need to be specific

Best practices should only be applied to processes that are considered basic. It should not be tied to ones that allow a company to differentiate themselves from the competition or address critical success factors (what an organization must do well in order to be successful strategically). You should limit the best practices to a few basic processes such as accounts receivable and accounts payable.

Ensure you understand what is involved in your roles and responsibilities. Many organizations don’t have the experience or qualifications to do some of the tasks that may be assigned to them without a lot of help from the vendors. An example of this is developing to-be business process documentation. If you don’t have a resource on your team with the skill set to do this, you may be setting yourself up for a vendor change order.

A good way to limit scope for both the vendor and the customer is by arranging a “paid-for” business needs analysis (BNA) or discovery process prior to signing any long-term contracts. This should not delay the implementation process as it is work that would need to be done anyway. It should also not be a full-blown design phase by the vendors. It should be enough work for the vendors to define scope clearly and provide a fixed or not-to-exceed fee to do the implementation. It will also involve deciding what to do with all the requirements that are not met out-of-the-box by the vendors which include customization or custom reports, 3rd party modules, changing the process and workarounds.

The vendors would rather close the deal without doing the discovery if possible but we think this is short-sighted. In the end, the vendors don’t want unhappy customers and taking this extra step will help reduce the risks of unexpected and costly surprises during the implementation.

ERP Cost Estimates

Buyer beware when estimating the costs of an ERP implementation. There are so many unknowns that make it really tough to avoid unpleasant surprises. The vendors are very reluctant to fix price anything when it comes to the services required because of the many unknowns – scope of work, who does what, capabilities and available time of buyer resources…. It’s especially difficult for the vendors in the early stages of the selection process. At the same time, the buyers want to have a decent ball park of costs before pursuing a potential solution.

But there are guidelines that will help. When it comes to license or annual fees, it’s fairly easy to come up with a number as it’s based on number of users and high level scope. You should be using a rule of thumb for the implementation services which can be estimated as a ratio of implementation to license fees as follows:

1:1 for a straight forward implementation with relatively simple requirements

1:5:1 for an implementation with some complexity of requirements and little or no customization

2:1 for an implementation with a lot of complex requirements and some customization

3:1 for an implementation with a lot of complex requirements as well as a lot of customization

Other costs to consider:

Maintenance – the vendors will provide a % but make sure that it includes adequate levels of support. The vendors have been pushing their maintenance %’s ever higher despite the competition. Assume at least 20%.

Travel – it can be as high as 15% of implementation fees

Upgrade fees – many systems that are installed on premise or on private clouds will have upgrade costs every few years which should be a small % of the implementation fees.

Internal costs – you need to know who will be involved and the extent of their time as well as their approximate cost to the company

Legal fees

Infrastructure changes – you need to get an idea of the recommended infrastructure for the new system and what it will cost to acquire and install it.

Consultant fees – you may want some coaching services from a company like 180 Systems.

August 2, 2013 from Computerworld – “David Steinour is at his wit’s end with enterprise software cost increases. In each of the past three years, the CIO at George Washington University (GWU) watched his annual maintenance and support costs for Oracle Financials and related enterprise software jump by at least 10%.

“Oracle works very well, but at the end of the day we pay a huge price for that service,” Steinour says.

Today, 99% of the fixed-cost increases in the university’s IT budget come from software maintenance price hikes. “That’s just not sustainable,” says Steinour, whose IT department supports 20,000 students and 1,600 faculty members…”

180 View – This problem will eventually undermine the leading ERP vendors who charge their clients a fortune in maintenance each year without providing enough value in return. Customers are between a rock and a hard place. Their systems work by and large but they hate the high costs of maintenance.

April 30, 2012 from CFO – “A CFO’s guide to the wild and wooly world of cloud services in which contracts are mutable, companies come and go, and politics a continent away could materially impact your business…”

180 View –Although we don’t think that cloud computing contracts are as risky as the article indicates, there are still some good suggestions.

March 23, 2011 from InformationWeek – “Can software licensing get any more ridiculous? My company recently concluded a $900,000 software purchase, after reviewing the products of three major vendors… I understand that our software vendors must earn returns that support continued investment and innovation. But how much time and effort would be saved by both parties with simpler, more transparent licensing methods? It’s time for a change.”

180 View – We too have seen a wide variety of pricing models making it difficult to compare costs by vendors. Don’t wait until a decision is made to know the fine print.

January 2011 from CAmagazine and written by Michael Burns – “A major acquisition such as an ERP system should be considered a lifetime investment. It’s not just a software purchase; it’s a contract that includes maintenance fees, which will exceed the cost of the software in four to five years. A good dose of due diligence is in order — not only in testing the software and assessing the vendor, but also in reading the contract… ”

September 7, 2010 from InfoWorld – “…Here are the top tips from consultants who help customers negotiate pricing, terms, and conditions with vendors such as Cisco Systems, EMC, Hewlett-Packard, IBM, Microsoft, Oracle, and SAP…”

180 View – There are a few good points if you’re new to negotiating with technology vendors. Remember that the ERP vendors in particular anticipate that their new clients will not want to change systems again and so they are more willing to negotiate license fees, terms and conditions but reluctant to negotiate maintenance fees. But in the heat of the deal, anything is possible.