ERP and Systems Project Interview Questions for Finance Leaders
Most senior finance leaders have run at least one system change.
A new ERP. A move to a cloud ledger. A consolidation tool, a planning system or a new payroll platform. These projects are expensive, slow and visible. Boards remember them, and so do the people who had to live through them.
That is why panels ask about them. They are not checking whether you know the software. They want to know how you made the case, how you handled the delays most projects face, how you brought people along and what you learned when it got hard.
Many candidates answer like a project manager. They list modules, phases and go-live dates. The panel wants something different. They want a business leader who can tell them what the system changed, what it cost and what went wrong.
This article covers the questions to expect, business case and benefits, delays and budget overruns, people and change, a project that went badly and full example answers.
The questions to expect
Tell us about a system implementation you led.
How did you build the business case?
What benefits did you promise, and did you deliver them?
How did you handle delays or budget pressure?
How did you bring the finance team and the wider business with you?
What would you do differently?
Tell us about a project that did not go to plan.
Our current system is ageing. How would you approach that decision?
Prepare one main project story you can tell from start to finish, and one shorter story about something that went wrong.
Business case and benefits
The business case is where boards first judge a finance leader on a systems project. They want to see that you were honest about cost and realistic about benefits.
A strong answer shows:
Why the change was needed. Risk, cost, growth or a system reaching end of life.
What options you considered. Including doing nothing or upgrading the current system.
Costs over the full life. Licences, implementation, internal time, training and support.
Benefits you could measure. Faster close, fewer manual steps, better data for decisions, lower risk.
Example wording: “The business case covered five years. We included internal team time, which is often left out, and set aside a 15% contingency. The benefits were mostly time and risk, not headcount, and we said so. I think that honesty is why the board approved it.”
If you promised benefits, be ready to say whether they arrived. “We targeted a five-day close and reached six days in the first year, then five in the second.” Panels respect a near miss explained honestly far more than a claim that everything landed perfectly.
Delays and budget overruns
Few large system projects finish on time and on budget. Panels know this. They are not testing whether you avoided all problems. They are testing how you responded when problems came.
Things worth talking about:
How you spotted the delay early
How you reported it to the CEO, board or steering committee
The choices you put forward, such as cutting scope, adding time or adding budget
What you decided and why
How the project finished
Example wording: “Three months before go-live, testing showed our data migration was not ready. I went to the steering committee with three options: go live on time with known risk, delay six weeks, or go live with a smaller scope. We chose the six-week delay. It cost $180,000 more, but we went live with clean data and closed the first month on time.”
Avoid blaming the software provider or the implementation partner. Even if they caused problems, blame sounds like you were not in control. Talk about what you did.
People and change
Systems projects often fail because of people, not technology. Panels know this too.
Show that you thought about:
The finance team. Who would be most affected, and how you supported them.
Business users. Managers who had to change how they approved purchases or read reports.
Training and support. Before and, just as importantly, after go-live.
Workload. How you kept business as usual running while people worked on the project.
Example wording: “We back-filled two senior roles in the finance team so the people closest to the process could work on the project full time. After go-live, we ran short weekly drop-in sessions for budget holders for three months. Questions to the help desk fell by half over that period.”
If your project changed or removed roles, say so plainly and explain how people were treated. Keep the detail general, as employment rules differ between Australia, New Zealand and organisations.
A project that went badly
You will probably be asked about a project that did not go well. Choose a real example. It does not have to be a disaster. A project that ran late, went over budget or failed to deliver a key benefit is enough.
Use a simple shape:
What happened
Your part in it
What you did to recover
What you changed afterwards
“We launched a new planning tool with a tight timeline because the board wanted it in place for the budget cycle. We did not test it with enough business users. The first budget round took longer than the old spreadsheets, and confidence in the tool dropped. I owned that. We paused, ran proper user testing and relaunched three months later. The second budget cycle was two weeks faster than before. Since then, I never let a deadline override user testing.”
For more on this type of question, see answering the failure question in executive interviews.
Example answers
Question: Tell us about a system implementation you led.
"As Group Financial Controller, I led the replacement of three separate ledgers with one ERP across our Australian and New Zealand businesses. The old systems were out of support and month-end took 12 working days because of manual consolidation.
I built a five-year business case of $4.2 million, including internal time and a contingency. The main benefits were a faster close, one set of data and lower audit risk. I chaired the working group and reported monthly to the CFO and audit committee.
We hit one major delay when data migration testing failed, and I recommended a six-week extension rather than going live with poor data. The project finished 4% over budget. Within a year, close was down to six days, audit adjustments fell sharply, and the CFO had one view of the group for the first time."
Question: How would you approach replacing our system?
“I would start by understanding what is not working today and what the business needs in three to five years, not by choosing software. I would talk to the finance team, key business users and IT. Then I would test whether an upgrade or better use of the current system could solve most of the problem. If a full replacement is needed, I would build a business case with honest costs, including our own people’s time, and a staged plan with clear decision points for the board.”
Question: What would you do differently?
“I would involve business users earlier. On my last project, finance designed the approval workflows, and some managers felt the system was imposed on them. Next time, I would have two or three budget holders in the design group from the start.”
How search consultants see it
When I worked in executive search, systems projects came up in many finance briefs. Often the hiring organisation had just finished a hard project, or was about to start one, and the board was nervous.
I listened for ownership. The candidates who stood out talked about decisions they made, numbers they tracked and trade-offs they put to the board. The ones who worried me described the project as something that happened to them, or spent most of the answer on what the provider got wrong. Clients wanted someone who could stay calm and in control when the project wobbled.
Linking it to your resume
Your system project should appear on your resume as a result, not a task. “Led group ERP replacement across Australia and New Zealand, cutting month-end close from 12 to 6 days.” See ERP and systems projects on a finance resume for more examples.
A quick self-check
Can you explain the business case for your main project in one minute?
Do you know which benefits arrived and which did not?
Can you describe a delay and the choice you made?
Do you have a story about a project that went badly, and what you changed?
Your next step
Write your main system project as a two-minute answer, covering the case, one problem, your decision and the result. Then write the shorter story about what went wrong.
If you want help preparing for senior finance interviews, my executive interview preparation helps senior leaders turn complex projects into clear, credible answers.
If you have an interview coming up and a systems project to explain, book a complimentary Clarity Session.
