Phase 1 Is Not the Finish Line: Where Your PSA Investment Actually Pays Back

Your PSA is not failing. It is drifting. There is a difference, and it is expensive.

If you read the last article on choosing the right implementation consultant, you already know the best ones are thinking past go-live from day one. This piece is about why that matters.

Most organizations I work with land somewhere in the middle of the SOMM. Level 3 or Level 4. The system is live. Reports are running. Timesheets are coming in with reasonable consistency. The pain that drove the implementation is gone, and the team has moved on to other priorities.

That is exactly when the ROI conversation should be starting. Most of the time, it is when it stops.

Why most teams stall at “good enough”

I get it. Implementations are exhausting. Once you cross the finish line, the last thing anyone wants to talk about is more changes to the system. The timesheets are flowing, the reports are running, leadership is happy enough. There is no fire to put out, so the urgency to keep improving disappears.

Here is what happens next:

• The configuration choices that made sense at go-live start to age

• The business evolves, and the system does not evolve with it

• New features get released on the platform that nobody adopts

• Reports get built but never trusted, so people quietly stop using them

• The “we will revisit this in six months” backlog turns into a graveyard

None of this is dramatic. It does not show up as a system failure. It shows up as a slow drift between what the platform could be doing and what it is actually doing for you.

That gap is where the ROI lives.

What gets left on the table

When I walk into an optimization engagement, this is what I most often find:

• Features that were never turned on. Either because they were not needed at go-live, or because they are newer additions to the platform that nobody flagged

• Configuration decisions that no longer fit. Made sense in year one, no longer match how the business operates in year three

• Workarounds that became permanent. A one-time workaround that someone built in month two, still being used four years later, with nobody quite sure why

• Reports that exist but are not used. Often because the people who needed them moved on, or the data underneath them stopped being trusted

• Manual processes that should not be manual. Steps the system could automate, still being done by hand because nobody had the time to figure out the better way

Most of it is not broken. That is the thing; the system works “Works” and “works well” are not the same standard, and the gap between them is bigger than most teams realize.

The optimization window is real, and it opens more than once

I wrote about this in the SOMM piece. Around the six-month mark, organizations start to understand what they have, and the change request list comes to life. That is the first optimization window, and it is a great one to take advantage of.

But it is not the only one.

Year two and year three are also high-leverage moments, especially if your business has changed shape. A new service line. A pricing model shift. A leadership change. A growth phase that put pressure on processes that were comfortable when the team was smaller. Any of those is a reason to revisit the configuration and ask whether the system is still serving the business.

The longer the gap between optimization touchpoints, the more drift accumulates, and the harder it is to unwind later. Small adjustments now beat a large rebuild in three years.

What an optimization engagement actually looks like

Optimization is different work from implementation;. You are not standing something up from scratch; you are walking into a live system with a team that has habits, history, and opinions.

The work usually breaks down like this:

• Discovery. Understanding what is actually happening in the system versus what leadership thinks is happening. These are rarely the same. People have built workarounds, side processes, and shadow systems that nobody at the top is fully aware of.

• Targeted recommendations. Not a rebuild. A list of specific changes, prioritized by impact, with a clear sense of what each one will take and what it will return.

• Execution. The actual configuration work, plus the change management around it. Optimization always has a people component because you are changing something the team has gotten used to.

• Knowledge transfer. Same as in implementation, this matters. Whatever changes get made should be documented and understood by your internal team, not locked up in someone else’s head.

  
  

A good optimization engagement is often shorter and more surgical than an implementation. The leverage comes from knowing where to look.

A pattern I see often

Here is a recent example, kept generic because the pattern shows up in a lot of organizations.

A client had a long list of service items in their accounting system. Hundreds of them. When they implemented their PSA, the instinct was to bring all of those service items over to the new platform. On the surface, it makes sense. Those service items represented real billing detail, and nobody wanted to lose visibility.

The problem is that those service items were not really service items in a PSA sense. They were job codes and billing rates, which belong in a different structure entirely. Bringing them over wholesale was creating configuration weight that did not scale, slowed down setup for new projects, and made the system harder to maintain.

The fix was not dramatic. We pivoted to a clean list of around six service items and moved the detailed billing structure to a different table, where it actually belongs. The client kept all of their reporting detail. They lost none of the business intelligence they cared about. What they gained was a setup that scales, aligns with leading practices, and makes future configuration changes much easier.

The point is not the specifics. The point is that this kind of mismatch sits inside a lot of live PSA systems, quietly creating drag, and most teams cannot see it because they are too close to the day-to-day. An outside set of experienced eyes can spot it in a few weeks. Fixing it pays back over years.

How to tell if you are ready for one

A short self-check. If more than two of these are true, you are probably overdue:

• It has been more than 18 months since anyone audited your configuration end to end

• Your business has changed in a meaningful way since go-live and the system has not been adjusted for it

• Reports are being run, but you are not sure leadership is using them to make decisions

• Your admin team has a backlog of “we will get to it” items that has been growing for a year or more

• New features have been released on the platform that nobody on your team has evaluated

• People are using workarounds that everyone treats as normal but nobody can justify if asked

  
  

You do not need all of these to be true. Two or three is enough.

The bottom line

Go-live gets you the ROI you set out to capture. The rest of what the platform can do? That is what optimization is for.

It is delivered over the years that follow, and how much of it you actually capture depends on whether you keep investing in the system as your business changes. The teams who treat optimization as ongoing, rather than as a one-time project, are the ones who get the most out of what they bought.

If your system has been live for a while and something in this resonated, that feeling is information. Worth listening to.