The short answer
A good implementation provider (for an ERP, CRM, integration, cloud migration or custom application) can show you five things before you sign:
- They understand the problem, and they asked hard questions before proposing a solution.
- They have a delivery method with stages, acceptance tests and a clear definition of "done".
- Their estimate is honest about assumptions, exclusions and what could change it.
- They handle your data and access responsibly, including any subcontractors.
- You will not depend on them forever: documentation, handover and exit are part of the plan.
Price matters, but a low estimate with vague scope is usually the most expensive option by the end.
Criteria that matter
Discovery before solution. A provider that proposes a product and a price after one short call has not understood your situation. Look for structured discovery: current processes, data, systems, constraints and who decides. Paid discovery for larger projects is normal and often worth it.
Relevant experience you can check. Ask for examples of similar work and for references you can call. Speak to a reference about what went wrong and how it was handled; every project has problems.
The people who will do the work. Ask who will actually configure, build, migrate and train, and whether they are employees or subcontractors. Meet the lead before you sign.
A method you can follow. Stages, deliverables at each stage, testing, and your approvals. You should be able to see progress in working software or configuration, not only in status reports.
Estimate quality. A good estimate lists assumptions, exclusions (licenses, hardware, third-party fees, work outside scope), dependencies on your team, and the main cost drivers. It should also say how changes are handled.
Security and data handling. How the provider stores credentials, who gets access to your systems and data, whether data leaves the United States, and what happens to copies at the end. NIST's work on cybersecurity supply chain risk management is a useful reference: look at a supplier's ownership and location, its security maturity and your own ability to manage the risk it introduces.
Handover and ownership. Who owns the configuration, custom code, integrations and documentation? Can your team, or another provider, pick up the work later?
Independence. If the provider resells software or earns fees from vendors, that is not wrong, but it should be disclosed so you can weigh their recommendations.
Legal and regulatory obligations to keep in mind
- Privacy. There is no single federal privacy law in the US, but your organization generally stays responsible for personal information it hands to a service provider. The FTC's data security guidance expects reasonable safeguards, state comprehensive privacy laws (such as those in California and Texas) typically call for written contracts with service providers, and HIPAA requires business associate agreements where protected health information is involved. Be clear with the provider, and with the people whose data it is, where data will be processed, including any processing outside the US.
- Regulated financial institutions. Financial institutions covered by the GLBA Safeguards Rule must oversee their service providers, and banks and credit unions should also look at the FFIEC IT Examination Handbook and the 2023 interagency guidance on third-party risk management, which cover due diligence proportionate to risk, written contracts and subcontracting.
- Accessibility. If the work produces public-facing websites or customer documents, confirm how accessibility will be handled (the ADA is applied to websites by courts, and we suggest targeting WCAG 2.2 AA).
This is general information, not legal advice.
Questions to ask any provider
Understanding and approach
- What do you understand our problem to be, in your own words?
- What would you need to find out before you could commit to a fixed scope?
- What would make you recommend we do not go ahead, or choose a different product?
Team and experience
- Who exactly will work on our project, and in which roles?
- Do you use subcontractors? Where are they based, and will they access our data?
- Can we speak to two clients with similar projects, including one where things went wrong?
Delivery and quality
- What are the stages, and what do we approve at the end of each?
- How will we test the work, and who writes the acceptance tests?
- How do you handle changes to scope, and how are they priced?
Estimate and commercial terms
- What does the estimate assume, and what does it exclude?
- Which costs are fixed, and which depend on time spent?
- Do you receive any commission or referral fee from the vendors you are recommending?
Security and data
- How do you store and share credentials for our systems?
- Where will our data be stored and processed during the project, and is any of it outside the United States?
- What happens to our data, access and copies when the project ends?
Handover, support and exit
- What documentation will we receive, and in what format?
- Who owns custom code, configuration and integrations?
- What support is available after go-live, and how are response targets agreed?
- If we move to another provider, how will you help with the transition?
Questions a good provider will ask you
A provider's questions tell you a lot. Expect them to ask who makes decisions, what success looks like, which systems and data are involved, what your team can commit, what is genuinely fixed (budget, deadline, regulation), and what has been tried before. If they ask none of this, be cautious.
Warning signs
- A firm price before anyone has looked at your data or processes.
- No written exclusions, or an estimate that says "everything included".
- Reluctance to name the people doing the work or provide references.
- Promises of specific savings or of no downtime at all.
- No mention of testing, training or handover.
- Contract terms that make it hard to take your data, code or documentation elsewhere.
Comparing providers fairly
Send every shortlisted provider the same brief: the problem, the systems involved, constraints, and any checklist you have completed (such as the ERP evaluation checklist or build, buy or integrate worksheet). Score their responses against the criteria above, with weights agreed beforehand. For ongoing IT support rather than a project, the criteria are different; see how to choose a managed service provider.
Limitations
No set of questions removes all risk. A provider can answer well and still deliver poorly, which is why stage-by-stage approvals, acceptance tests and the ability to change course matter more than any single answer.
Next step
You are welcome to ask us every question on this list. Our approach is described on how we work. If you want an independent view before choosing a provider or a platform, see IT consulting and advisory.
Sources and further reading
Product capabilities and guidance change. These are the primary sources this article relies on, checked on the review date above.
- NIST Computer Security Resource Center (cybersecurity supply chain risk management), National Institute of Standards and Technology
- Data security guidance for businesses, Federal Trade Commission
- IT Examination Handbook, Federal Financial Institutions Examination Council
- Gramm-Leach-Bliley Act, Federal Trade Commission
This article is general information, not legal, accounting or security advice for your specific situation. Examples are hypothetical unless stated otherwise.