The Complete PSA Implementation Checklist
- 10 hours ago
- 4 min read
Before, during, and after go-live, the same five gaps keep showing up.
Every implementation I have worked on breaks in the same handful of places. Not a software bug, not a missing feature. The same five things, showing up in a different order depending on the project.
That is the useful part. If the failures were random, there would be nothing to prepare for. They are not random. After enough projects you start seeing the same gaps open in the same sequence, and once you can name them you can close them before they cost you anything.
I built a checklist around those five: 20 checks across the whole arc of an implementation, from before you sign to a year after go-live. Here is what each gap is, and why it is on the list.
1. Before you sign: leadership alignment
The gap that opens earliest and costs the most.
Implementations do not fail because leadership was against them. They fail because leadership was vaguely for them. Someone approved the budget, everyone nodded, and nobody wrote down what success actually looks like or who owns the answer when two departments disagree.
You find out this alignment was missing about four months in, when finance and services want the project structure to work two different ways and there is no one whose job it is to decide.
The check: before you sign anything, can you name the one person who breaks a tie between departments? If the answer is a committee, you do not have alignment. You have a meeting.
2. During implementation: operational ownership
Somebody inside your organization has to own this system. Not the consultant, not the executive sponsor who attends the monthly steering call. Someone who uses it, understands why it is configured the way it is, and will still be there in a year.
When nobody owns it, the system drifts. Configuration decisions get made by whoever is in the room, nobody remembers the reasoning six months later, and the first person to leave takes half the institutional knowledge with them.
A good build does not make you dependent on whoever built it. It makes you the owner.
The check: name the owner. An actual person, with this in their objectives, not a role that exists on a slide.
3. During implementation: configuration scope
The instinct almost every team has is to rebuild what they had before. I understand it. Change is exhausting and the old way at least works.
But rebuilding your old workarounds in a new system just buys you a more expensive version of the same mess. A new platform is the one moment you get to ask why you do it this way at all, and that window closes fast once configuration starts.
The opposite failure is just as common: configuring for a process nobody actually follows. If the documented process and the real process are different, you will configure for the documented one and your team will work around it by week three.
The check: for each major process, has someone asked why before asking how? And does the process you are configuring match what people actually do?
4. Before go-live: user acceptance testing
The gap teams are most tempted to skip, because by the time you reach it everyone is tired and go-live is circled on the calendar.
Real UAT means testing to your process, not testing that the system technically functions. Those are different things. Clicking through screens tells you the buttons work. It does not tell you whether your billing rules hold up against the way finance actually recognizes revenue.
Teams that skip this do not avoid the problems. They just meet them after go-live instead of before, when they are harder and more expensive to fix. This is what real UAT looks like if you want the longer version.
The check: have the people who will use this daily run their own real scenarios end to end? Not the project team, who know how it is supposed to work.
5. After go-live: where you land on the maturity curve
The last gap is the one nobody expects, because it opens after the project is over.
Go-live is not the finish line. It is the start of a different phase, and how you handle the next twelve months determines whether the system becomes an asset or an expensive habit. Six to nine months in, your change request list comes to life. Around month twelve, the pressure to act on it fades and that list becomes a graveyard.
Knowing which stage you are actually in tells you what work to do next, and it is different work at every stage. That is what the Services Operations Maturity Model is for.
The check: do you know what stage you are in, and what that stage specifically asks of you?
How to use the checklist
Work through it honestly. That is the only instruction that matters, and it is harder than it sounds, because the temptation on every one of these is to check the box on the strength of a conversation somebody had once.
If you check most boxes, you are in strong shape. If a section has more gaps than checks, that is exactly where to focus next. The point is not the score. The point is knowing which of the five is most likely to be the one that bites you.
The PDF is fillable, so you can check boxes directly in it rather than printing it out.
The Complete PSA Implementation Checklist
20 checks across five sections: leadership alignment, implementation ownership, configuration scope, UAT, and where you land on the maturity curve after go-live. Fillable, so you can work through it on screen.
Where to go from here
If you want a more precise read on where your organization lands on that last one, the self-assessment does it in under five minutes.
More gaps than checks?
That is a normal result, and it is more useful than a clean sheet, because now you know where to start. If you want a second set of eyes on the ones that worry you most, let's talk.
