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.
