IFRS 17 Resource Gaps and Challenges: The People Problem Nobody Planned For
Every IFRS 17 programme I have been involved in underestimated the resourcing challenge. Not the cost of resources — most budgets account for that reasonably well — but the availability of the specific skill sets at the specific moments they are needed, and the transition of knowledge from the project team to the business-as-usual team. This gap tends to be invisible at kick-off and inescapable at go-live.
This is a practitioner’s view of the resourcing problem: what the skill shortage actually looks like, why the consultant market has not solved it, what internal teams are being asked to carry, and what the handover to BAU looks like when it has not been planned for.
1. The specialist skill shortage is real
IFRS 17 requires a combination of skills that did not exist as a bundle before the standard. A programme needs people who understand the accounting logic, the actuarial modelling implications, the data pipeline, the vendor product, and the disclosure requirements — often in the same person when the team is small. Individuals with all of that experience are genuinely scarce, not artificially scarce.
The market has adjusted slowly. Early implementation programmes trained their own specialists because nobody else had the experience. Those specialists are now senior consultants, partners, or in-house leads — and are fully booked on programmes that started eighteen months before yours did. The people available to hire today are usually a tier more junior than the people you actually need.
This scarcity is not uniform across phases. Gap analysis and FIA skills are now reasonably commoditised. Methodology, CSM calculation logic, and vendor-specific configuration expertise remain tight. Post-implementation skills — parallel run reconciliation, audit liaison, BAU process design — are the tightest, because the people who know them are still finishing the build on earlier programmes.
2. The consultant market is not a one-to-one replacement
Most insurers assume that where internal capacity is short, consultants will fill the gap. That is partially true and structurally limited. Consultants solve the capacity problem but introduce three other problems.
First, the best consultants are unavailable. The same scarcity that drove the insurer to the market applies to the consulting firms. Quoted rates are for the resource pool, but the named partner or lead who won the pitch is unlikely to be the person on the tools day to day. Insurers who confirm lead-consultant assignments in writing, not just in the proposal, tend to get better outcomes.
Second, consultant knowledge does not transfer automatically. A consultant who configures a vendor solution flawlessly can leave at go-live with the entire operating knowledge of the configuration in their head. If the insurer has not budgeted for a structured knowledge transfer — documentation, shadowing, and overlap with BAU staff — the programme ships on time and then breaks six months later when the consultant is gone.
Third, consultant costs scale faster than expected. IFRS 17 programmes routinely run 30–50% over their original consulting budget, not because the daily rates changed but because the scope of specialist input kept expanding. Every methodology decision drew in an extra review. Every vendor query needed a specialist walkthrough. The original resource plan assumed internal staff would carry chunks of work that, in practice, required consultant hours.
3. Internal capacity is already committed
The harder problem is that the internal team assigned to IFRS 17 is usually not net new. Actuaries on the programme are the same actuaries running solvency, embedded value, pricing, and reserving. Finance team members on the programme are the same people closing the books every month. Data engineers on the programme are the same people keeping the production pipelines running.
“Carve-out” resourcing plans assume these people can be allocated 60–80% to IFRS 17 without impairing their BAU delivery. In practice, the carve-out rarely holds. BAU work expands to fill the available time, IFRS 17 deliverables slip, and the programme discovers the slippage at steering committee two months after it happened.
The teams that manage this best do one of two things. They either backfill BAU explicitly — hiring or seconding resources into the current operational team so IFRS 17 staff can genuinely step back — or they accept explicit BAU degradation during the build phase, documented and signed off by the executive committee. Both work. What does not work is assuming the team will absorb the load.
4. Parallel implementation pressure compounds everything
Most IFRS 17 programmes are not the only change happening in the insurer. Finance transformations, ledger upgrades, risk capital framework changes, solvency regime reforms, and data platform migrations are often running in parallel. Each of those programmes is competing for the same internal specialists, especially actuarial, finance transformation, and data engineering resources.
The parallel-programme effect shows up in three places. Steering committee conflicts — the same executives are sponsoring multiple programmes and cannot focus. Resource conflicts — the same specialists are named on multiple programmes’ critical paths. And data conflicts — changes in one programme’s data model break assumptions in another’s. The insurers who handle this best maintain a single enterprise-level resource plan that surfaces the overlaps before they become blockers, not after.
5. The handover from project team to BAU
The most under-planned part of any IFRS 17 programme is the transition from build mode to run mode. Go-live is treated as the finish line. It is not. Go-live is the point at which a small, expert, highly-engaged build team has to hand off to a larger, less specialised, operationally-focused BAU team — with a close cycle that now needs to be executed monthly or quarterly, at pace, by people who did not build the solution.
The handover gap manifests in predictable ways. BAU teams discover undocumented manual steps that the build team treated as “obvious”. Reconciliations that the build team ran every quarter in a week now need to run every month in three days, and the process does not scale. Vendor configurations that only the build lead fully understands become a single point of failure when they leave for the next programme.
The mitigation is not complicated in principle but is expensive in practice. It requires the build team to spend the last three to six months of the programme in shadowing mode — BAU staff leading, build staff observing and correcting — rather than handing over via documentation alone. It requires runbooks that cover not just what to do but what to do when things go wrong. And it requires the build team to stay accessible, at some cost, for the first two close cycles after go-live.
6. The team you need after go-live is different
The skills required to build an IFRS 17 solution are different from the skills required to run it. Build needs specialists who can make methodology decisions, configure vendor products, and reconcile across systems. Run needs process operators who can execute a close cycle, spot anomalies, and know when to escalate. The two populations overlap but do not coincide.
Most programmes under-estimate how much senior specialist capacity they still need post-go-live. Methodology questions keep arising. Regulator queries land. Vendor product upgrades require re-validation. The BAU team that was sized for “normal finance operations with an IFRS 17 overlay” tends to be undersized for the first two years. Insurers that realise this in the programme phase and plan the BAU organisation accordingly avoid the “we went live and then the team quit” pattern that has shown up more than once in the market.
7. What to do about it
There is no tidy solution. There are, however, decisions that materially improve the odds:
Start specialist hiring and contracting before you need them. By the time the requirement is on the critical path, the people are gone.
Plan BAU backfill explicitly. Either hire it or accept BAU degradation openly.
Contract named consultant leads, not the consulting firm. Lock in who will actually be on the tools.
Budget for knowledge transfer as a deliverable. Three to six months of shadowing is cheaper than the alternative.
Plan the post-go-live organisation in the programme phase, not after. The build team you have is not the run team you need.
IFRS 17 is the most resource-intensive regulatory change most insurers have ever run. The technical complexity is largely solved — products exist, methodologies are stabilising, the playbook is visible. The resourcing challenge is the one still costing programmes time and money, and the one most under-planned at kick-off. Treating it with the seriousness it deserves is the highest-leverage thing a steering committee can do.
Continue reading
Related reading
IFRS 17 Post-Implementation Challenges: 6 Operational Issues and How to Address Them
Go-live is where the real work starts. Here are 6 operational challenges that surface after IFRS 17 implementation — and practical approaches to each.
Read →IFRS 17 Actuarial Disclosure Items: What the Standard Actually Asks For
The IFRS 17 disclosure requirements drive the entire measurement architecture backwards from reporting day. A practitioner's view of the actuarial disclosure items the standard asks for — reconciliations, time-bucket analyses, judgements — and what each of them implies for the projection engine.
Read →Why Are We Implementing IFRS 17? A Practitioner Revisits the Case
Midway through a build, the question of whether IFRS 17 is worth the cost comes up often. A practitioner's walk through the IASB's stated motivations — what actually improves, what gets harder, and where the standard is unusually elegant.
Read →Reference
Tools & references
Working on something similar?
I've delivered IFRS 17, AI advisory, and actuarial training across 15 jurisdictions. If this topic is relevant to your team, let's talk.