What to ask before you sign an enterprise software contract

Choosing business software is rarely about features. Most leading ERP, CRM and finance products can do most of what a typical business needs. What differs is the total cost, the effort required, the fit with your processes and the quality of the team that implements it. Those factors are settled, or left unsettled, in the contract.

Panorama Consulting’s 2023 research, reported by Statista, found that 47% of ERP implementations had cost overruns. Overruns rarely come from nowhere. They usually trace back to assumptions that were never tested before signing: about how much customisation is needed, how clean the data is, or who will do the work. The questions you ask before you sign are the cheapest risk control you have.

This guide groups those questions into five areas. Use them in vendor and partner meetings, and insist on written answers that can be attached to the contract.

Questions about fit

Fit decides how much of the project is configuration and how much is custom development. Configuration is relatively cheap and survives upgrades. Custom development adds testing, support and upgrade cost every year for the life of the system.

• Which of our core processes will the standard product support without change?
• What must be configured, and what must be custom built? Can we see that list by process?
• Who owns the fit-gap analysis, how detailed will it be, and will we see it before the contract is final?
• Where do you recommend we change our process to fit the product, and why?
• Which similar organisations run the same processes on the standard product today?

Be suspicious of a quote produced before any fit-gap work. If a partner can price the project without understanding your processes, they are either pricing a template or planning to recover the difference through change requests.

Questions about cost

The initial quote is rarely the total cost. Licences, hosting, support, upgrades, internal staff time and post-launch improvements often exceed the implementation fee over five years. Ask for a complete picture.

1. What is included in the quote, and what is explicitly excluded?
2. How are changes priced, and who approves them?
3. What are the licence, hosting, support and upgrade costs in years two to five, and how can they rise?
4. What happens if the project takes longer than planned, and who bears the cost of delay?
5. How many days of our own staff time does the plan assume, and from which roles?

The last question is often overlooked. A plan that assumes your finance manager will spend half their time on the project for nine months has a real cost, even if it never appears on an invoice. If that person cannot be released, the schedule will slip.

Ask, too, how the quote was built. A fixed price sounds reassuring, but it is only as good as the scope behind it. If the scope is loose, a fixed price simply moves the argument to the change-request process. A time-and-materials quote with a well-defined scope, a clear estimate and regular reporting against budget can be safer than a fixed price built on guesswork.

Questions about delivery

The people who sell the project are not always the people who deliver it. The skills and continuity of the delivery team matter more than any methodology slide.

• Who will actually work on our project? Can we meet the project manager and lead consultants before signing?
• What is their experience in our industry and with organisations of our size?
• How will our data be cleaned and migrated, who does the cleaning, and how many trial migrations are planned?
• What does testing look like, and who writes and runs the test scripts?
• What does training look like by role, and how much support is provided after go-live?
• How will success be measured after go-live, and over what period?

Data migration deserves particular attention. Most organisations underestimate how much of their customer, supplier and product data is duplicated, incomplete or out of date. A plan with a single migration rehearsal is a warning sign. Two or three rehearsals, with reconciliation of balances each time, is more realistic.

Testing is the other area where plans are often thin. Ask to see an example test plan from a previous project. It should cover individual functions, end-to-end processes such as order to cash, integrations with other systems, and user acceptance testing by your own staff using realistic data. If testing is described in a single line of the plan, expect to discover problems after go-live rather than before it.

Questions about the exit

Nobody likes to discuss the end of a relationship at the start, but exit terms protect you if the partner underperforms, the product is acquired or your business changes direction.

A good partner will answer these plainly. Reluctance to discuss exit terms often signals a business model that depends on making departure difficult.

Questions to ask yourselves

Not every risk sits with the vendor. Before signing, the buying organisation should be honest about its own readiness.

• Do we have a senior sponsor with time and authority to make decisions quickly?
• Have we agreed which processes we are willing to change?
• Do we know who owns each master data area, and is the data in a fit state to migrate?
• Can we release the right people from their day jobs for the duration?

If the answer to any of these is no, fixing it before signing will save more money than any discount negotiated on the licence.

How to use the answers

Collect the answers in a single comparison document, with one column per shortlisted partner. Score each answer for clarity and completeness, not just for the most attractive number. A partner who gives a higher estimate with a clear explanation of assumptions is often a lower risk than one who gives a lower estimate and avoids detail.

Then attach the most important answers to the contract as schedules: the fit-gap summary, the named delivery team, the migration and testing approach, the cost assumptions for years two to five and the exit terms. Answers that live only in meeting notes or sales presentations are easy to forget and hard to enforce. Answers in the contract become shared commitments that both sides can refer back to when the project meets its first difficulty.

The takeaway

Treat the contract as the start of a working relationship, not the end of a procurement exercise. If answers are vague now, delivery will be vaguer. Ask for references from organisations of similar size and complexity, speak to them directly, and ask what they would do differently. Then put the important answers in writing before you sign.

Source: Panorama Consulting ERP report 2023, as reported by Statista.

Frequently asked questions

Why do ERP projects overrun on cost?

Usually because assumptions about customisation, data quality and staff availability were not tested before signing. Each gap becomes a change request later.

Should we sign before the fit-gap analysis is complete?

Ideally not. At minimum, agree a paid discovery phase that produces the fit-gap before the main implementation contract is fixed.

What exit terms matter most?

Data export in a standard format, ownership of customisations and documentation, and clear notice periods and fees for ending support.

Explore Enterprise software implementation