A PSA implementation is an operating-model change supported by software. The project succeeds when sales, delivery, finance and people operations use the same definitions and the new system produces trustworthy decisions. This checklist focuses on the sequence, evidence and ownership required to reach that point.
Phase 1: define ownership and success
Name one executive sponsor and one accountable process owner for each critical flow: sales handoff, resource allocation, time approval, project economics and billing. The implementation team may configure the platform, but only business owners can decide what “correct” means.
Choose a small set of success measures before configuration. Useful examples are invoice cycle time, percentage of timesheets approved on schedule, projects with an updated forecast and hours spent preparing the staffing meeting. Record the baseline and the target date.
Phase 2: map decisions and minimum workflows
Map the decisions the system must support, not every historical exception. Start with the path from qualified opportunity to staffed project, approved time, recognized work and invoice. Document the entry criteria, owner, required fields and control at each handoff.
Separate launch requirements from later improvements. A common failure is reproducing years of spreadsheet customization before users have completed one standard cycle. Protect a minimum viable operating model, then add exceptions only when evidence shows they are frequent and material.
Phase 3: prepare and migrate data
Create a data register listing source, owner, field definition, quality issue, retention rule and destination. Clean clients, people, skills, rates, projects and opening balances before import. Do not use migration to preserve duplicate, stale or ownerless records.
Run at least two rehearsals. After each import, reconcile record counts and a sample of business totals such as active projects, contracted value, cost rates and unbilled work. Log transformations so that finance and operations can explain where every opening number came from.
Phase 4: configure controls and integrations
Configure roles according to job responsibility and least privilege. Test who can see cost rates, candidate data, commercial terms and financial exports. Define approval delegation, audit history and the process for joining, changing role and leaving.
Test integrations as end-to-end scenarios rather than isolated API calls. A successful test follows one opportunity through project creation, staffing, time approval and billing, including an error and a retry. Record which system owns each field to avoid silent overwrites.
Phase 5: pilot a complete business cycle
Select a representative pilot: enough projects and contract types to reveal problems, but small enough for daily support. Include a supportive manager and at least one skeptical user. Run real work through the pilot and rehearse month-end before expanding.
Use a visible issue log with severity, owner, decision and due date. Distinguish configuration defects, bad source data, unclear policy and training gaps. Fixing the wrong category with more software customization creates permanent complexity.
Phase 6: launch, adoption and stabilization
Publish role-based instructions around tasks people actually perform. Give managers dashboards for missing approvals and exceptions. During the first cycles, hold short office hours and answer questions in the workflow, then update the shared guidance.
Define exit criteria for parallel systems: two reconciled billing cycles, agreed data quality and no unresolved critical control. After launch, review adoption and outcome measures at 30, 60 and 90 days. The PSA pricing guide helps keep the implementation effort inside the approved TCO.
Final go-live checklist
Before go-live, confirm owners, permissions, migrated balances, integration monitoring, backup and export, support contacts, month-end rehearsal and rollback steps. Every critical item needs evidence and a named approver. “The vendor says it is ready” is not an acceptance test.
Close the project only after responsibility has moved to normal operations. Record remaining improvements in a prioritized backlog, schedule a quarterly data-quality review and keep definitions visible. A PSA becomes valuable through consistent operating discipline, not through launch day alone.
Early signals that the rollout is drifting
Four signals appear before the problem is visible in the plan. The first is the reappearance of parallel spreadsheets for decisions the system should already support: a data point is missing, or nobody trusts the one that exists. The second is a customization request list growing faster than it closes, almost always a symptom of undecided policy. The third is project meetings run only by external consultants and IT, without business process owners. The fourth is a go-live date that stays fixed while scope expands.
None of the four is solved by adding hours. They are solved by returning a decision to the business, cutting launch scope, or moving the date transparently.
What to do when the pilot does not work
A pilot that goes badly is cheap information, provided it is not read as a verdict on the product. Before deciding anything, sort the issues into configuration defect, bad source data, unclear policy and training gap, then look at the proportions. If source data and unclear policy dominate, the problem is yours and it is solved without touching the system. If genuine defects dominate, that is a conversation with the vendor and probably a delayed launch.
The expensive middle option is launching anyway with a promise to fix things later. Switching off the previous system with open issues leaves the firm without a safety net during close, and the cost of rebuilding the team's confidence far exceeds a month of delay. Keep the rollback documented and tested until two complete cycles have closed cleanly.
