Perhaps your board has approved a new eligibility pathway, or leadership has changed application or exam pricing. Perhaps you’re switching test vendors and moving from a single annual window to rolling testing, or your recertification committee has shortened the renewal window.
Each of these is a reasonable decision made for good reasons—and each one lands on your team the same way. Someone has to reconstruct how the certification management system was built in the first place, and how to navigate the back end to change it, and make sure the user experience isn’t adversely affected. (If you’re lucky, you have a support team that can assist with these questions). Then comes figuring out how long the change will take, bridging the gap with spreadsheets, rewriting candidate communications, and thinking through the inevitable exceptions.
That’s the operational burden of certification policy changes, and it’s why configurability matters in your software. Here’s where time actually goes during a policy change.
Where the Time Goes in a Policy Change
Ask your team how long a policy change will take, and they’ll likely answer with the implementation: two days to reconfigure the application, a week to update the renewal rules. That’s the part with a clear start and end.
Implementation is rarely what consumes the calendar. A policy change moves through six phases, and only one of them is the change itself:
- Discovery: Relearning how your system was built and what it can support.
- Scoping: Determining what has to change, and what else it touches.
- Waiting: The gap between knowing what you need and having someone available to build it.
- Bridging: Holding candidates together with spreadsheets while the system catches up.
- Implementation: The change itself, plus updating every communication and instruction that references the old rule.
- Exceptions: Managing candidates caught between the old policy and the new one.
Take a new eligibility pathway as an example. Discovery means figuring out which application questions are conditional and what your platform can support without outside help. Scoping means determining whether the change needs new branching, what documentation changes, which communications reference the old rules, and what happens to applicants already in progress. Waiting is the gap before anyone can act. Bridging means tracking the new pathway’s applicants on a side sheet until the system catches up. Implementation is when the branching finally gets built. Exceptions are the tail: candidates who applied under the old rules, asking whether the new pathway applies to them.
Four of those six phases (discovery, waiting, bridging, and exceptions) produce nothing of value. They exist because the system can’t absorb policy changes on its own terms. They’re also the four that vary most from program to program. Implementation takes what it takes; whether the rest costs you an afternoon or a quarter comes down to one question: is the change a setting your team adjusts, or code someone else has to write?
When it’s a setting, discovery is short because the configuration is visible to the people using it. Waiting is zero. Bridging and exceptions never start, because the system is current before the first candidate hits the new rule.
When the system is custom-built or hard-coded, all four expand together, and discovery becomes a research project, waiting becomes a queue you don’t control, and bridging and exceptions accumulate for as long as that queue lasts.
It’s the same decision from your board, but two very different quarters for your team.
The Costs That Never Reach the Project Plan
The six phases above price a single change, on its own. Two other costs never appear on that timeline, however, because they only become visible across your program over time.
Changes overlap. No program handles one at a time. The bridging period for a new eligibility pathway runs into the discovery phase for a vendor switch, which runs into the implementation of a new retake policy. Your team isn’t working through a sequence of projects. They’re managing a permanent overlap, which is why the work feels continuous even when each individual change looked manageable on approval.
Good ideas stop reaching the board. This is the cost that never gets counted, and it’s a big one. After implementation has been slow enough times, teams start filtering their own agenda. Someone raises an idea, a new pathway or a pilot, and someone else observes that the system won’t support it. The idea closes before it becomes a proposal. No project opens. No delay is recorded. The credential quietly stops evolving at the pace of the profession it serves.
That last cost rarely appears in an operations review, and it carries the longest consequences. A certification that can’t adapt is competing against ones that can.
What Configurable Software Actually Changes
Configurability means the rules that define your program are settings your team can adjust, not code a vendor has to rewrite. That distinction decides whether the four unproductive phases stay small or take over the quarter.
A custom build solves today’s change by writing it into code, which means the next change has to be written into code too: back to a developer, back to a queue, back to paying for the modification. Each change makes the next one more expensive instead of cheaper. (We covered this trade-off in “Why You Need Configurable (Not Custom) Software.”)
There are three questions worth asking honestly about your current system:
- Can you set up your rules the way your program actually defines them, without workarounds?
- Can you implement a board’s decision yourselves, and see what it affects before you do?
- And when you need help, is there someone on the other end who understands credentialing?
When the answer to all three is yes, a policy change becomes work your team scopes and finishes on its own timeline, inside one system, alongside the AMS or LMS you already depend on.
Your board will keep changing policy. That’s a sign of health, not a problem to solve. What varies is how much of that decision’s cost goes to work that produces nothing. As the credentialing industry’s most configurable platform, ROC-P is built to keep that cost as close to zero as possible.
If your team is absorbing policy changes through workarounds and development requests, it’s worth pricing what that’s costing you. Connect with our expert team to talk through what your certification program needs next.