By the time most companies reach the contract stage with an ERP implementation partner, due diligence has typically covered two things: confirming the firm holds a current Microsoft designation, and checking a couple of references. Both are worth doing — but neither one reliably predicts whether your specific project will go well, because neither addresses the questions that actually determine day-to-day project experience: who's staffing it, what happens when something goes wrong, and what support looks like after go-live, when the sales relationship has effectively ended.
Here's a checklist covering what due diligence usually misses.
Staffing Questions
Who specifically will be running my project, day to day — not who ran the sales process? The person who impressed you in discovery calls isn't necessarily the person who'll be available for questions six weeks into implementation. Get a specific name and role, not a description of "our team."
What's that person's current workload, and how many other active projects are they juggling? A consultant spread across too many concurrent engagements, however capable individually, has less bandwidth for your specific project than the sales conversation implied.
What happens if that person leaves the firm or gets reassigned mid-project? Firms with a real answer to this — documented handoff processes, shared project context, backup staffing — are meaningfully different from firms who haven't thought about it because it hasn't come up in this conversation before.
Escalation and Communication Questions
What's the actual response time commitment for a blocking issue during implementation — not a general SLA, but what happens specifically? Vague answers ("we're very responsive") are less useful than a specific process: who gets contacted, how quickly, and what the escalation path looks like if the first response isn't sufficient.
How are project risks and scope changes communicated, and how often? A firm with a defined, regular cadence for surfacing risk — not just a final "we're on track" update — is signaling a more mature, transparent project management approach than one relying on ad hoc updates only when something's already gone wrong.
Post-Go-Live Support Questions
What does support look like in the first 30, 60, and 90 days after go-live — specifically, not just "ongoing support included"? This is the period where real-world usage surfaces issues that testing didn't catch, and it's also frequently where firms scale back attention once the contract's primary deliverable is technically complete.
Is post-go-live support the same team that ran implementation, or a separate handoff to a different support function? A clean handoff to a well-prepared support team can work fine; a handoff that loses project context and institutional knowledge is a real risk worth understanding before signing, not after.
What does a typical support request turnaround look like once the project is formally closed? Ask for specifics — average response time, how requests are prioritized — rather than accepting "we're here if you need us" as a sufficient answer.
Client-Fit Questions
What does your typical client look like, by size, and where would I fall in that range? Covered in more depth elsewhere in this series, but worth including directly in a pre-signing checklist: a firm whose typical client is meaningfully larger than you is likely to staff and prioritize your project differently.
Reference-Check Questions Worth Asking Specifically
Generic reference calls tend to produce generic answers. More useful questions to ask a reference directly: "Did the person who ran your discovery calls stay involved through go-live?" and "What did support actually look like 60 days after go-live, specifically?" These get at exactly the gaps a standard reference call often misses.
Why This Checklist Matters More Than It Seems
None of these questions are exotic or unreasonable to ask. They're uncomfortable in a way that generic due diligence isn't — asking a firm directly about workload, staffing turnover risk, and what happens after the sales relationship ends requires a level of specificity many buyers skip, either because it feels awkward or because it doesn't occur to them until the answer would have mattered.
A firm confident in its staffing model, escalation process, and post-go-live support will answer these questions plainly and specifically. Hesitation, vagueness, or redirected answers are data points worth weighing as seriously as anything in a formal proposal.
The Practical Takeaway
Certifications and references are a reasonable starting filter, covered in more depth elsewhere in this series — but they're not sufficient due diligence on their own. Before signing, run through the staffing, escalation, post-go-live, and client-fit questions above directly with any firm on your shortlist. The specificity of the answers you get back tells you more about how the actual project will go than anything in a sales proposal.