First published on LinkedIn on 9/24/2026.
------------
Let's play a quick game.
Pick a number between 12 and 48.
Got one?
Now ask yourself: Why that number?
Maybe it was random. Maybe it was lucky. Maybe it had some personal meaning. Either way, you picked a number.
But what if that number suddenly represented something real?
What if it represented the number of events you had to host at your house next year?
If you love planning menus, rearranging furniture, and pretending your house always looks that clean, 48 might sound fun. If you have one bathroom, a nervous dog, and a deep need for quiet weekends, 12 may already feel ambitious.
The point is simple: once a number has consequences, we ask better questions. We want to understand what it means, how it will be used, and what impact it will have.
Yet in the pension administration industry, it feels as though we're collectively accepting a number without asking enough of those same questions.
Over the past year, and especially at two major public pension conferences I recently attended, I've heard the same message repeated again and again: PAS implementations should not take more than 24 months. The more I hear that number in presentations, industry discussions, and modernization conversations, the more I find myself wondering how we collectively landed on it as the answer.
What I question is not the desire to move faster, but the assumption that every implementation should fit within the same timeframe. Unlike our little game, the number attached to a modernization project carries very real consequences for cost, risk, quality, and outcomes.
Over the past couple of decades, PAS modernization has evolved from heavily customized systems to configurable COTS platforms and, more recently, SaaS-based solutions. Instead of building each system from scratch, the industry has moved toward leveraging proven capabilities while still accommodating the requirements that make each organization unique.
That evolution should help reduce implementation timelines. Proven products, repeatable approaches, and lessons learned from past projects have made it possible to deliver value faster than was realistic fifteen or twenty years ago.
What I struggle with is how that progress turned into a single benchmark when every agency has different levels of complexity, different challenges, and different readiness.
A pension system serving 50,000 members under one benefit plan is not the same as one serving a million members across multiple plans and structures. Data quality differs. Integrations differ. Governance models differ. Organizational readiness differs.
Proven solutions can reduce the effort required to modernize, but they do not eliminate the factors that make each implementation unique. The goal should be to accelerate delivery through better products, better tools, and better approaches — not force every project into the same timeline because the industry has become comfortable with a particular number.
Which brings me back to the question: where did that number come from?
We can probably all agree on one thing: a PAS modernization should not take ten years — or seven, or in most cases, even five.
The industry has made real progress. Modern platforms are more mature, methodologies are more refined, and agencies and vendors have learned from past modernization efforts.
There are good reasons to push for shorter timelines. Agencies want value sooner, sponsors want less risk, and vendors are delivering more mature, configurable products than they were fifteen years ago.
So yes, it is reasonable to expect timelines to shrink. But somewhere along the way, that reasonable expectation became a specific one: 24 months.
Why 24?
Why not 22 months? Why not 26?
Is that number grounded in successful implementations, agency complexity, and realistic stakeholder readiness? Or did it just sound specific enough to be credible and short enough to be marketable?
My concern is what happens when a benchmark becomes a requirement. The conversation shifts from “What timeline is appropriate?” to “How do we force this implementation into the timeline?”
Those are very different questions.
AI and automation add another layer to the discussion. Requirements analysis, configuration, testing, documentation, and data validation can now be completed more efficiently than they could just a few years ago. That is a good thing.
But technology has limits. Pension modernization is not just software deployment; it is business transformation shaped by data quality, governance, stakeholder engagement, change management, training, and validation of the rules that directly affect member benefits.
So the real question is: how much can technology truly accelerate, and how much still depends on people, processes, and organizational readiness?
Technology can compress certain activities, but not every part of a complex implementation moves at the same speed. Faster configuration does not automatically speed up stakeholder decisions. Better testing tools do not replace business validation. Improved data utilities do not fix underlying data quality issues
Before we declare any single timeframe the industry standard, we should first understand the assumptions required to make that timeframe successful.
The right question is not whether every implementation should take 24 months. The right question is what conditions must exist to make any timeline achievable.
Proven products and AI can help us move faster, and we should take advantage of every responsible opportunity to do so. But the achievable schedule still depends on factors that vary significantly from one pension organization to another:
I do not believe there is a one-size-fits-all timeline for a PAS implementation. Twenty-four months may be achievable for one agency and a gross underestimate for another based on its plans, data, integrations, stakeholder community, and readiness.
Vendors should propose timelines and budgets that are ambitious, realistic, and grounded in the actual work required. A timeline that looks attractive during procurement but requires extensions, change requests, or additional funding ultimately serves neither the agency nor the vendor.
Competition should push every vendor to improve, and Sagitec is no exception. We should continue looking for ways to work faster, become more efficient, and deliver better outcomes. But we should not follow a timeline trend that simply transfers risk to the client.
The right number is not the one that sounds best in a proposal or fits most neatly within a timeline graphic. It is the shortest timeline in which the agency and vendor can responsibly deliver a solution that is adopted, ready for production, and built for long-term success.
The question is not whether 24 is the right number. The question is whether we understand enough about the project before we pick any number at all.
I would like to hear from others: What additional considerations have you encountered when establishing a realistic implementation timeline, and what factors have you seen successfully help reduce one?