Your PSA Implementation Is in Trouble. Here Are the Signs.

The warning signals most teams miss, and why they show up on both sides of the table.

Most troubled implementations do not announce themselves. There is no single moment where everything clearly goes wrong. What actually happens is quieter than that. Things drift. Small decisions get deferred. Engagement from the right people starts to thin out. The team keeps moving forward, but the foundation underneath is shakier than anyone is willing to admit.

By the time something feels officially broken, the real damage was done weeks or months earlier.

After more than a decade of working on PSA implementations, I have learned that the practitioners who catch problems early are the ones who know what to look for. And they know to look in two places: at the client organization, and at the implementation team itself.

Both sides of the table carry risk. Both sides can quietly derail an otherwise solid project. Here is what that actually looks like in practice.

On the client side

Decisions keep getting deferred. “We’ll figure that out later” is one of the most expensive phrases in a PSA implementation. Every deferred decision is a gap that someone will eventually fill, and that someone is usually the consultant, working from an assumption rather than a confirmed requirement. When a team consistently avoids making decisions during the implementation, it is almost always a sign that the right people are not engaged, the internal ownership structure is unclear, or both.

The internal owner is not really owning it. Every implementation needs a person on the client side who is genuinely responsible for driving decisions, keeping internal stakeholders aligned, and showing up prepared. When that person is pulled in too many directions to engage meaningfully, the project fills the vacuum with assumptions. This is not a criticism of busy people. It is a structural risk that needs to be named and addressed early, because it compounds over time.

Testing is being treated as a checkbox. I have written about UAT at length because I believe it is the single most underfunded and undervalued phase of any implementation. When a team schedules a few hours before go-live and considers that sufficient, they are not testing the system. They are hoping it works. Those are very different things, and the difference shows up immediately after go-live.

Scope is expanding without anyone acknowledging it. New requirements surface in nearly every implementation. That is normal. What is not normal is when those requirements get absorbed into the project without any formal discussion about what gets added, removed, or reprioritized as a result. Unacknowledged scope expansion is how timelines slip and budgets erode without anyone being able to explain exactly why.

Leadership went quiet after kickoff. Early executive enthusiasm that disappears mid-implementation is a pattern worth paying attention to. When leadership is visibly engaged, the rest of the organization tends to follow. When they check out, the signal travels downward whether anyone intends it to or not.

On the implementation team side

This is the part that does not get talked about enough. Client-side warning signs get most of the attention, but some of the most significant implementation risks sit on the other side of the table entirely.

The PM is reporting status instead of managing risk. There is a meaningful difference between a project manager who fills out a status report and one who is actively thinking five steps ahead. A strong implementation PM anticipates risks before they become issues, holds the team accountable to quality and timelines, and maintains real visibility into what every member of the team is actually doing. When that proactive thinking is absent, problems do not get surfaced until they are already expensive to fix.

Nobody on the team knows what the team is actually doing. This sounds like an exaggeration. It is not. When a PM does not have genuine insight into the day-to-day work of their team, quality suffers quietly and consistently. Work gets submitted that has not been reviewed. Gaps go unnoticed. The client experiences the impact before the PM does.

Junior or disengaged consultants are doing work that is not being reviewed. Less experienced consultants are a completely normal part of delivery. Every team has them, and there is nothing wrong with that. The problem is when their work passes through to the client without adequate oversight. The difference between a junior consultant who grows and contributes meaningfully and one who creates rework and erodes client confidence is almost always the quality of the oversight they receive.

The team is executing without thinking. An implementation team that takes requirements at face value, without asking whether those requirements reflect the client’s actual business needs, will deliver exactly what was asked for. That sounds fine until you realize that what was asked for and what was actually needed are frequently not the same thing. The best implementation teams push back thoughtfully. They ask the clarifying questions that surface the real requirement underneath the stated one.

---

What to do when you spot these signs

Recognizing these signals early is valuable precisely because early gives you options. A deferred decision that surfaces in week three is a conversation. The same deferred decision surfacing two weeks before go-live is a crisis.

The instinct to wait and see if things improve on their own is understandable. In my experience, it is almost never the right call.

If you are seeing these signs on your current project, whether you are on the client side or the implementation side, the most important thing you can do is name what you are observing and have the direct conversation it calls for. That is easier said than done, and the way you do it matters enormously.

Want to go deeper? I've put together a practical companion guide to this article for PS Playbook members: a structured checklist for evaluating both sides of the table, plus how to raise each warning sign without damaging the relationship or the project. Get the companion guide →