The Post-Go-Live Review Should Count the Work That Escaped the System

A practical weekly article for community-bank and credit-union leaders on finding the spreadsheets, shared mailboxes, reconciliations, and manual work that appear after a techno...

A technology rollout can hit every milestone and still leave the institution carrying more work than it had before.

The system launched. The project plan closed. The vendor moved the implementation team to its next customer. The steering committee saw a green status. Someone brought pastries.

Then the real operating model showed up.

A loan processor built a spreadsheet because one exception did not fit the new workflow. A branch employee started keeping a paper log because the search screen took too long. Operations added a daily reconciliation because two systems disagreed. The contact center created a shared document to explain the screens customers were seeing.

None of those workarounds necessarily means the rollout failed.

But they do mean the rollout is not finished.

For community banks and credit unions, the post-go-live review should not be a ceremonial meeting where everyone admires the launch date. It should be a governance checkpoint that asks where work escaped the approved system, why it escaped, and what risk followed it.

That is the part the board and executive team need to understand.

The project plan sees delivery. Operations sees the debt.

Technology projects are usually measured against visible commitments: scope, schedule, budget, defects, training, adoption, and uptime. Those measures matter. They tell leadership whether the institution received what it approved.

They do not always show what employees had to invent afterward.

A manual workaround may be sensible for a short period. It can protect customers while a vendor fixes a defect. It can keep a critical process moving during stabilization. It can help a team learn where the new workflow needs adjustment.

The trouble begins when temporary work becomes invisible work.

A spreadsheet becomes the real exception queue. A shared mailbox becomes the approval path. A branch checklist replaces a missing system control. A daily reconciliation becomes permanent because nobody owns the underlying mismatch.

Now the institution has two operating models: the one described in the approval packet and the one employees actually use.

That gap is technology governance.

It changes the control environment, staffing load, evidence trail, customer experience, and risk profile. If the post-go-live review only asks whether the application is stable, leadership may miss the work that moved outside it.

Example one: the OCC treats launch as the beginning of monitoring

OCC Bulletin 2017-43 addresses risk management for new, modified, or expanded bank products and services. It tells banks to align new activities with strategy, use sound risk management, establish controls, and monitor the activity after implementation.

Source: Office of the Comptroller of the Currency, “New, Modified, or Expanded Bank Products and Services: Risk Management Principles,” October 20, 2017: https://www.occ.treas.gov/news-issuances/bulletins/2017/bulletin-2017-43.html

That last part matters.

Approval is not proof that the operating assumptions survived contact with the real world. The evidence comes after employees, customers, vendors, data feeds, exception rules, and deadlines begin interacting at full speed.

For a community bank, imagine a new commercial onboarding workflow. The formal system captures ownership information, required documents, approvals, and risk reviews. But after launch, lenders start emailing missing documents directly to operations because the portal does not handle one common entity type well.

The workflow may still be live. The dashboard may still show adoption. Yet part of the evidence chain has moved into email.

The post-go-live review should catch that.

For a credit union, the same issue might appear in a digital account-opening process. The system routes standard applications cleanly, but address mismatches and identity-verification exceptions land in a manually maintained list. If that list has no aging rule, review owner, or escalation path, the exception process is now carrying more governance weight than the system leadership approved.

This is why ongoing monitoring should include workflow drift, not only system performance.

Example two: FFIEC guidance connects development to business controls

The FFIEC Development, Acquisition, and Maintenance booklet frames system work as a life-cycle discipline. It covers governance, project management, development and acquisition practices, implementation, change management, and the controls needed to support reliable systems.

Source: FFIEC IT Examination Handbook, “Development, Acquisition, and Maintenance”: https://ithandbook.ffiec.gov/it-booklets/development-acquisition-and-maintenance.aspx

The practical lesson is straightforward: implementation is not just a technical event. It changes how the institution performs work.

That means a post-go-live review should compare the designed workflow with the operating workflow.

Where are employees leaving the system?

Which fields are being copied into spreadsheets?

Which approvals happen in chat, email, or on paper?

Which reports require manual correction before a committee can use them?

Which customer or member requests take longer because the new process created an extra handoff?

These questions are not an attack on the project team. Quite the opposite. They give leadership a chance to distinguish useful stabilization from unmanaged control drift.

No implementation is perfect. Pretending otherwise is how small workarounds grow into important systems that nobody budgets, tests, backs up, or reviews.

A spreadsheet does not become less consequential because it arrived without a purchase order.

Example three: NIST makes change control an evidence problem

NIST Special Publication 800-53 Revision 5 includes controls for configuration change control, security impact analysis, access restrictions for change, system monitoring, and assessment. The control catalog is not a banking rulebook, but it offers a useful discipline: changes should be authorized, analyzed, tested, documented, and reviewed as part of an organization-wide risk process.

Source: National Institute of Standards and Technology, “Security and Privacy Controls for Information Systems and Organizations,” SP 800-53 Rev. 5: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

Boards do not need a tour of every configuration control. That sounds like a reliable way to make good people regret joining the board.

They do need assurance that the implemented environment still matches the approved control story.

If employees create a side process after launch, ask what changed:

1. Did the workaround move sensitive data? 2. Did it create a new approval path? 3. Did it weaken segregation of duties? 4. Did it remove an audit trail? 5. Did it create a dependency on one person? 6. Did it change recovery, retention, or access requirements?

A workaround can be small and still alter all six.

That is why the post-go-live review should treat employee-created tools and manual reconciliations as configuration facts, not cultural trivia.

What should be in the post-go-live packet

A useful review packet can be short. Five exhibits are enough to make the conversation real.

Show the approved process beside the process employees actually follow. Highlight extra handoffs, duplicate entry, manual approvals, paper steps, shared mailboxes, and local files.

List each temporary tool or process, its owner, purpose, data used, control impact, expiration date, and permanent resolution. “Everyone knows about it” is not a field.

3. The exception and queue report

Show volume, aging, rework, overrides, abandoned cases, complaints, and manual touches. A stable application can still support an unstable operation.

4. The control comparison

Confirm whether access, approval, retention, reconciliation, audit evidence, and recovery still work as approved. If the real process changed, the control assessment should change with it.

5. The decision list

Name what will be fixed, accepted temporarily, redesigned, retired, or escalated. Give each decision an owner and a date. Otherwise the review becomes a very organized description of tomorrow’s problem.

The board question is not “Did it launch?”

A launch date is useful. It creates focus. It gives the institution a point to plan around.

It is not the finish line for governance.

The better question is whether the institution can now perform the work safely, consistently, and explainably without depending on invisible processes.

That question belongs in the steering committee, the operations committee, the risk committee, and sometimes the board packet. The level of detail will differ, but the governing principle does not.

Management should know where work escaped the system.

It should know whether those workarounds protect service or quietly weaken controls.

And it should decide what happens next before temporary becomes traditional.

Technology debt rarely arrives wearing a sign. Usually it arrives as a helpful spreadsheet created by someone trying to get through Tuesday.

The post-go-live review is where leadership decides whether that spreadsheet is a bridge, a warning, or the institution’s newest unofficial system.

Discussion questions

1. After our last major rollout, which manual workarounds, spreadsheets, shared mailboxes, or duplicate entries appeared, and who owns the decision to remove or govern them? 2. Does our post-go-live packet compare the workflow we approved with the workflow employees and customers actually experience? 3. Which temporary process created during stabilization has no expiration date, control review, or permanent resolution?