Questions to Ask When Implementing a New System
For anyone leading or joining a system rollout: an ERP, a CRM, a scheduling platform, a case management tool. Twenty questions to put to the sponsor, the vendor, and the people whose daily work is about to change.
The questions
Open any question for the note
What breaks today that made us decide to do this?
Why ask it
Start with the pain rather than the plan, because the pain is what the rollout will be judged against. If the answers are abstract, someone bought a product before naming a problem, and scope will expand to fill the gap.
A year after go-live, what has to be true for us to call this a success?
Why ask it
You want two or three numbers with owners attached: days to close, average handling time, error rate, licence spend. Answers about improved visibility or better collaboration cannot be measured and therefore cannot be missed.
Who signed off on this, and who is allowed to stop it?
Why ask it
Projects with a diffuse sponsor stall at exactly the moment they need someone to overrule a department. Ask for one name for decisions and one name for the budget, and notice if they are the same person or nobody.
Which existing system is being switched off, and on what date?
Why ask it
Rollouts that never retire anything become a second system running alongside the first, with staff quietly using whichever is faster. A committed decommission date is the clearest evidence that this is a replacement rather than an addition.
Who owns this system after go-live, and is that written into someone's job?
Why ask it
Configuration, permissions, and vendor escalations need a named owner with allocated hours, not a volunteer. Systems without an owner drift within a quarter: stale user lists, unused fields, workarounds that harden into practice.
Which teams were consulted before we chose this, and which were not?
Why ask it
The teams that were skipped are where resistance will surface, usually after the contract is signed. Their objections are often practical rather than emotional, so hearing them late costs configuration changes at the worst time.
How many people have to change what they do daily, and what are they doing now?
Why ask it
The count tells you the size of the change, and the current process tells you how big the gap is. A team using spreadsheets and personal habits will feel a structured system as a loss of speed before it feels like a gain.
What data comes across, what stays behind, and who decides?
Why ask it
Migration scope is where timelines quietly double, and where nobody notices historical records were dropped until an auditor or a customer asks. Push for a written rule per data type, including how far back and in what state.
How dirty is the data we are migrating, and who is cleaning it?
Why ask it
Duplicate customers, blank required fields, and free-text values that should be codes all have to be resolved by someone with domain knowledge, not by the implementation partner. Ask who that person is and what they are being taken off to do it.
Which integrations have to work on day one, and which can wait?
Why ask it
Integration lists tend to be aspirational, and every item on them consumes engineering time nobody has yet counted. Forcing a day-one versus later split is often the single biggest reduction in launch risk available.
Who is building the integrations, and have they read the actual API documentation?
Why ask it
Vendor sales decks describe capability; the documentation describes rate limits, missing endpoints, and fields that are read-only. Someone technical should confirm the specific integration is possible before dates are promised.
What are we deliberately not doing in the first phase?
Why ask it
A project without an explicit exclusion list has an implicit one that emerges as broken promises. Written exclusions also give you something to point at when a stakeholder arrives in week six with a new requirement.
How will we test with real data before go-live, and who does the testing?
Why ask it
Testing done by the implementation team validates the build; testing done by the people who use the system finds what the build got wrong. Ask for named testers, released from other duties, working from their own real cases.
What is the cutover plan, and can we roll back?
Why ask it
You are asking for the hour by hour sequence, who is on call, what runs in parallel, and the point of no return. A team that cannot describe the rollback has not thought through the worst weekend of the project.
What does training actually look like, and who is being paid to attend?
Why ask it
A recorded webinar and a slide deck is not training for someone who processes forty transactions an hour. Ask about hands-on sessions in a sandbox, timing relative to go-live, and coverage for the shifts people are pulled from.
What is the plan for the first two weeks after launch, when the tickets arrive?
Why ask it
Support demand spikes hardest immediately after cutover, which is often when consultants roll off. You want floor-walkers, a triage channel, a daily fix cycle, and someone empowered to change configuration same-day.
What is the total budget, and what is not in it?
Why ask it
Licences are usually the smallest line. The ones that get left out are implementation partner overruns, internal backfill, integration development, data cleanup, and year-two support at a higher rate.
Which of our own people are on this project, and what did they stop doing?
Why ask it
Internal capacity is the constraint that sinks the most rollouts, because nobody's existing workload was formally removed. If the answer is that they are doing both, the project is running on unpaid overtime and will slip.
What has to be right on day one for security, privacy, or audit reasons?
Why ask it
Access controls, retention rules, audit logging, and any regulated data handling are expensive to retrofit and awkward to explain. Get the compliance owner to review the configuration before cutover rather than after the first review.
What happened the last time we rolled out a system here, and what would make you tell us to delay?
Why ask it
Institutional memory is the cheapest risk register available, and the people who lived through the last one will tell you exactly where it went wrong. The second half of the question gives cautious colleagues permission to name the thing they are all worried about.
Running a System Rollout Without Breaking the Business
Practical guidance for the conversation itself
Before the Project Starts
Write the Success Criteria Before the Vendor Does
If the measures come from the vendor's business case, they will be measures the product happens to move. Agree two or three internal numbers, take a baseline reading now, and store it somewhere you will find it in a year. Projects without a baseline get judged on mood, and mood after a rollout is always poor.
Name One Decision Maker and One Budget Holder
Steering committees are useful for information and useless for decisions. Someone has to be able to say no to a department head in week five without convening a meeting. If that person does not exist, the project will settle every dispute by adding scope.
Set the Decommission Date at the Start
The old system is the real competitor. Put a switch-off date in the plan, tell the people who rely on it, and decide what read-only access remains for historical lookups. Rollouts that leave the legacy system running indefinitely end up funding both.
Budget for Backfill, Not Just Licences
The people you need on the project are the people who already carry the most operational load. Either buy temporary cover or accept a visible drop in throughput and say so up front. Pretending both can happen is how good staff burn out mid-project.
Warning Signs in the Answers
- A timeline with no time allocated for data cleanup. Cleanup always happens, so a plan without it is a plan to do it during testing.
- The phrase we will configure that later, applied to anything involving permissions or retention. Later means after someone has already seen data they should not have.
- A go-live date chosen to match a fiscal boundary or an executive's calendar rather than readiness. Ask what would have to be dropped to hold that date, and you will learn what is really being cut.
- Nobody can name the person who will own the system next year. That answer predicts the state of the system in eighteen months better than any other.
- The implementation partner's plan ends at go-live. The first fortnight after cutover is when you need them most.
- Training described only as materials or access to a knowledge base. Reading about a system is not the same as having done the task once under supervision.
- An integration promised on the strength of a sales conversation, with no engineer having opened the documentation.
Who to Ask What
The Executive Sponsor
- 1What has to be true a year from now for this to have been worth it?
- 2Who can stop this, and who can overrule a department that refuses?
- 3What is not in the budget?
- 4What would make you agree to delay?
The Vendor or Implementation Partner
- 1Which of your last five implementations most resembles ours, and may I speak to them?
- 2What do clients typically underestimate about their side of the work?
- 3Which parts of our requirement list need customisation rather than configuration?
- 4Who from your team is on this, at what percentage, and when do they roll off?
- 5What does support cost in year two and beyond?
The People Who Will Use It Daily
- 1Walk me through how you do this task today, including the parts not in the process document.
- 2What do you do when the current system will not let you do something?
- 3What would make the new one slower for you than what you have now?
- 4What is the busiest week of your year, and are we launching near it?
Whoever Will Support It Afterward
- 1How many tickets a week do you expect from this, and do you have the headroom?
- 2What access and documentation do you need before you will accept handover?
- 3What in this configuration will you be unable to fix without the vendor?
Common Pitfalls
Automating a Process Nobody Has Examined
Rebuilding a bad workflow inside new software makes it faster and harder to change. Before configuration, walk the process with the people who run it and cut the steps that exist only because the old system required them. Every one of those steps costs money to reproduce.
Treating Adoption as a Communications Problem
Resistance is usually rational: the new system takes longer for a specific task, or removes a shortcut somebody relied on. Ask which tasks got slower, then fix the worst of them. Newsletters and launch events do not survive contact with a form that now needs four extra clicks.
Customising Early
Every customisation becomes an upgrade problem and a documentation gap. Run the standard configuration through a full test cycle first, and only customise what genuinely blocked real work. Requirements written before anyone touched the software are the least reliable ones you have.
Launching Everything at Once
A phased launch by site, team, or module gives you a small population to fix things with and a group of experienced users to help the next wave. Big-bang cutovers make sense when the systems are genuinely inseparable, and are otherwise a way of concentrating all your risk into one weekend.
Letting the Consultants Leave at Go-Live
Contracts that end at cutover leave you alone in the fortnight when the most urgent configuration changes are identified. Negotiate hyper-care into the original agreement, with a named person and a response time, rather than as a change order once problems appear.
Skipping the Post-Launch Review
Three months after go-live, go back to the success criteria and read them honestly. Some will have been met, some will be worse, and some will turn out to have measured the wrong thing. Recording that is what makes the next rollout in your organisation less painful.