What to Look For in a PSA Implementation Consultant (And the Questions to Ask Before You Sign)
- 2 days ago
- 6 min read
The best consultants will tell you no. The ones to avoid will tell you anything you want to hear.
If you are reading this, you are probably somewhere in the middle of a decision. Maybe you have signed the contract for a PSA platform and you are figuring out who is going to help you stand it up. Maybe you are still evaluating, weighing options, and trying to understand what you are actually buying. Either way, the consultant you choose to lead your implementation will shape the next two years of your operations more than the platform itself will.
I say that as someone who has spent over a decade implementing and optimizing PSA systems, primarily SuiteProjects Pro. I have seen what good consulting looks like, and I have walked into plenty of post-implementation cleanup projects where the wrong fit caused damage that took years to undo.
So let me share what to look for, and what to ask, before you sign.
Platform expertise is the floor, not the ceiling
Anyone you bring in should know the platform deeply. That is the price of admission. They should be able to talk fluently about the modules, the configuration options, the gotchas, the things that look easy in a demo but get complicated in real life.
But here is the thing: knowing the software is not the same as knowing how to use it for your business.
The consultants who consistently deliver good outcomes are the ones who understand professional services as a business. They understand utilization, realization, project margin, resource management, revenue recognition. They know what a services org actually does day to day. Without that, you end up with a consultant who can configure anything you ask for but cannot tell you whether you should be asking for it in the first place.
They should know your world, not just their tool
Every services organization is different. Different verticals, different delivery models, different client profiles, different reporting needs. A consultant who walks in with a single playbook and tries to apply it across every engagement is going to miss things that matter.
What you want is someone who:
Asks more questions than they answer in the first few weeks
Spends real time understanding your delivery model before recommending configuration
Recognizes the difference between finance, services, and IT priorities and helps you navigate the tug-of-war between them
Can translate between those groups when they are saying the same thing in different language
That last one is bigger than it sounds. A lot of implementation friction is just three departments speaking past each other. A good consultant catches that early and keeps everyone aligned.
They push back when you ask for the wrong thing
This is the one I would pay the most attention to.
A consultant who says yes to everything is not protecting you. They are protecting their hours and their relationship with you in the moment. The consultants worth hiring will tell you no, and tell you why.
The two patterns I push back on most often:
The copy-and-paste trap. When a client wants to replicate exactly what they had in their old system, even when the new system can do it better. A new platform is an opportunity to revisit the why behind your processes, not just rebuild your old mess in a new place.
The over-customization trap. When a client wants every edge case handled at go-live. The bells and whistles. I have written about this before. Most teams overestimate how much customization they need on day one, and the customizations they build at the start often need to be rebuilt six months in because the underlying process changed.
A good consultant will tell you when something is going to cost you more than it is worth, and they will give you a real reason. If everything you ask for gets a thumbs up, that is information.
I worked with a client recently who had a list of hundreds of service items in their accounting system, and they wanted to bring all of them into the PSA. It was not the right move. Service items at that level of granularity were really job codes, and they belong in a different table for tracking and reporting purposes. We pivoted to a clean list of around six service items and moved the detail to where it actually serves them. It took some explaining and some credibility on my end before they bought in. The new structure scales with their growth, does not paint them into a corner, and it preserves their reporting detail. That is the kind of pushback you want from a consultant. Not pushback for the sake of it, but pushback grounded in experience and aimed at your long-term success.
They build for ownership, not dependency
Your goal is for your team to own the system. To understand it, run it, evolve it. The consultant is there to set you up, not to become a permanent fixture.
Watch for:
Documentation that lives with you, not with them
Knowledge transfer that is built into the project plan, not tacked on at the end
A configuration approach that your internal admin can actually maintain
A consultant who actively trains your people instead of keeping the keys
If at the end of the engagement you cannot make a configuration change without calling them, something went wrong along the way.
They take UAT seriously
User Acceptance Testing is where you find out whether the system you have configured actually works the way your business needs it to. It is also the phase that gets cut first when timelines slip.
A consultant who rushes you through UAT, or who treats it as a formality, is protecting their go-live date, not your business. Real UAT means real test scripts, real scenarios, real time blocked on calendars. The investment pays back the day after go-live.
If you want the longer version of why this matters, I recently wrote about it. Short version: testing to your process, not to a checklist, is what separates a smooth go-live from a painful one.
They think past go-live
Implementation is phase one. The best consultants are already thinking about phase two while they are configuring phase one. They are flagging the things that should wait, the optimizations that will make sense once your team has lived in the system for six months, the features you are not ready for yet but will want later.
A consultant who treats go-live as the finish line is going to leave you with a system that works on day one and slowly stops working as your business evolves. The ones who set you up well are the ones who see the implementation as the start of a longer arc. A good consultant sets you up to mature into Levels 3 and 4 of the SOMM, not just survive Level 2.
I will say more about that in the next article, because it is its own conversation.
Questions to ask before you sign
If you are interviewing consultants right now, here are the questions I would put on the table:
How many implementations have you led on this specific platform? Not adjacent platforms. This one.
Walk me through your discovery and requirements process. What does the first month look like?
How do you handle disagreements between finance, services, and IT during configuration decisions? Real answer, not a generic one.
What is your philosophy on customization at go-live? If they say “we build whatever you need,” dig deeper.
How do you approach UAT? Specifically, who builds the test scripts, who executes them, and how do you decide when the system is ready?
What does knowledge transfer look like? When you are gone, what does my team know how to do on their own?
What does success look like to you, six months after go-live? This tells you whether they are thinking past the project plan.
Can you walk me through a recent engagement that went well, and one that did not? What did you learn from each?
The answers will tell you a lot. So will the way they answer. A consultant who has been in the weeds for years will give you specific, sometimes opinionated answers. A consultant who is still learning will give you generic ones.
The bottom line
A good PSA implementation consultant is an investment that pays back over years. The wrong one costs you twice: once during the engagement, and again when you have to fix what they built.
The platform matters. The consultant matters more. Ask the questions. Take the references seriously. And if your gut is telling you something is off in the sales process, listen to it. Implementations are long, and you are going to be working with this person closely. Choose accordingly.
