Why PSA Implementations Fail (And It's Rarely the Software)

Most PSA implementation failures have nothing to do with the software. Here are four root causes and what to do about each one.

Let me say something that might be a little controversial in the PSA world: most implementation failures aren’t caused by technology.

I’ve worked on more SuiteProjects Pro (formerly OpenAir) implementations than I can count, and the thing that derails projects almost every single time? It’s not a software bug. It’s not a missing feature. It’s people, process, and expectations; usually some combination of all three.

Here are the four biggest culprits I see and what you can do about them.

1. Misaligned Leadership Expectations

This one is probably the most common, and the most painful, because it often doesn’t surface until you’re already mid-implementation and someone in a leadership meeting says, “Wait, I thought this system was going to do _____.”

Here’s what usually happens: expectations are shaped early, often during the demo and sales process, before the real requirements work begins. Demos are compelling and the software looks great in a controlled environment. But a demo is not a requirements discovery session. There’s a big difference between seeing a feature exist and understanding whether it maps to your specific workflow.

This isn’t always a “sales problem.” Sometimes it’s a lack of deep-dive requirements gathering on the front end. Sometimes the right people simply weren’t in the room when decisions were being made. C-level leaders and department heads often have very different ideas about what they’re getting. Is this a finance system? A services system? Who owns it? Who drives the configuration decisions and what are our reporting needs? Those questions need to be answered before you ever touch a single setting in the system.

The misalignment between what the C-suite thinks they bought and what the delivery or operations team actually needs is real, and it creates friction throughout the entire project.

What to do: Get alignment early, across all levels of leadership. Document what the system is for, who owns it, and what success looks like. And when in doubt, have the hard conversations before the contract is signed, not after.

2. No Ownership of Operational Design

Someone has to own this. And I mean really own it... not just show up to the calls, but take responsibility for documenting, defining, and making decisions about how the system will work for your business.

This is where I see a lot of companies struggle. They come into an implementation hoping the consultant (me!) will figure it all out for them. And while I absolutely bring deep expertise in the platform, I don’t know your business the way you do, nor will I be owning the system. My job is to configure the system to fit your world; understanding and defining that world is yours. While I absolutely can, and often do, recommend processes, operational design is a separate engagement entirely, and without that internal ownership, even the most well-configured system will fall flat.

A few things that trip teams up here: First, there’s often a tug-of-war between departments: finance wants it configured one way, services wants it configured another, and IT thinks they should be running the whole show. All three are valid stakeholders. But there must be a collaborative process where teams communicate, align, and move forward together. No silos. No surprises. Where teams land on the services operations maturity model often shapes how much resistance you will hit during this phase.

Second, many of companies fall into the “copy and paste” trap; they want to replicate exactly what they were doing in their old system. I get it. Change is hard. But here’s the thing: a new system is an opportunity. It’s a chance to revisit your processes, to ask “why are we doing it this way?” and get a thoughtful answer. If you just rebuild your old mess in a new tool, you’re going to end up with... a new mess.

One of the first things I tell every client: use your current process as a foundation, not a blueprint. Start there, yes, but then make intentional adjustments based on what the new system can do. Document as you go. Build something better.

What to do: Designate a clear internal owner (or ownership team). Hold regular internal meetings about the implementation; don’t let the only conversations about progress happen on calls with the consultant. Communicate across departments, early and often.

3. Poor User Acceptance Testing

I’m going to say something here that I say to every client I work with: UAT is not optional. And I mean real UAT, not “we clicked around for an hour and it seemed fine.”

Testing is the phase where you validate that the system you’ve configured actually works the way your business needs it to work. And the only way to do that effectively is to test to your process. Document your process. Communicate your process. Then build test scenarios that reflect the actual work your team does every day.

Is this tedious? Absolutely. Does it take time that feels nearly impossible to carve out on top of your regular job? Yes. But I promise you, the time you invest in thorough testing before go-live will pay dividends on the other side. Going live with minimal hiccups is genuinely something to celebrate.

(Truthfully, UAT deserves its own article entirely, and one is coming. Stay tuned.)

What to do: Treat testing like it matters, because it does. Block time on calendars. Build real test scripts based on real scenarios. Don’t sign off until your team has validated the system against the work they actually do.

4. Over-Customization Too Early

I call this the “bells and whistles” problem. Everyone wants everything configured perfectly on day one. The fancy dashboards, the custom workflows, the automated everything. And while there are legitimate use cases for customization, most teams overestimate how much they need at go-live.

My rule of thumb? Keep it simple (the KISS method applies here). Solve for 80% of your scenarios out of the gate. Don’t customize for the exceptions, the edge cases, the “what if this one client does this weird thing once a year.” Those 20% scenarios aren’t worth the time and money it takes to build for them upfront.

Here’s why: your requirements will change. I guarantee it. Once your team has lived in the system for three to six months, they’ll have a completely different understanding of what they actually need versus what they thought they needed. Customizations you built on day one may turn out to be unnecessary, or worse, may need to be rebuilt because the underlying process changed.

Resist the urge. Go live with a clean, functional configuration. Let the team get comfortable. Then revisit.

What to do: Prioritize core functionality at go-live. Create a backlog of “nice to haves” and revisit at the 3-6 month mark. You’ll make better decisions with real usage data.

The Bottom Line

Your PSA system is a powerful platform. When it’s implemented well, it genuinely transforms how a professional services organization operates. But the software is only as good as the implementation behind it, and the implementation is only as good as the people, the processes, and the preparation that go into it.