A PSA budget is credible only when it includes more than the subscription. The economic decision combines licenses, implementation, data migration, integrations, internal project time and the cost of operating the old stack during transition. This guide gives consulting leaders a repeatable way to build that budget without relying on a vendor's headline price.
Start with the operating problem, not the license
Write down the processes the new system must improve: opportunity handoff, staffing, time capture, project control, billing and forecasting. For each process, estimate today's manual effort, error risk and delay. A low license price has little value if the firm must keep separate tools for CRM, resource planning or invoicing.
Define the population that will actually use the product. Some vendors charge every employee, others charge managers or active users, and others use modules or usage. Model expected headcount and role changes for three years so that a pricing model that looks attractive today does not become a penalty during growth.
The six components of total cost
Use six budget lines: recurring subscription, initial configuration, data migration, integrations, internal change effort and ongoing administration. Request each line separately in the commercial proposal. If a supplier bundles them, ask for assumptions, included hours and the rate applied to extra work.
Internal effort is real even when no invoice is issued. Include the time of the executive sponsor, process owners, data owners, pilot users and finance reviewers. Also include parallel running, because many firms keep spreadsheets or a legacy system for one or two closing cycles while they validate outputs.
Build a three-year TCO model
The basic formula is: three-year TCO = recurring fees + one-off services + internal effort + transition cost + expected change requests. Apply the same scope and headcount scenario to every finalist. Show the base case, a growth case and a downside case in which implementation takes longer.
Do not mix recoverable taxes with economic cost, and do not hide annual price increases. Record currency, payment timing, indexation, minimum commitment, renewal notice and exit fees. A simple table with one column per year is usually more useful than a complicated ROI spreadsheet.
Compare value with a measurable baseline
Link the budget to outcomes the firm can observe: days from month-end to invoice, late timesheets, manual reconciliation hours, unbilled work, forecast preparation time and percentage of projects with a current margin view. Capture the baseline before implementation and assign an owner to each measure.
Keep benefits conservative. Count time savings only where the work can actually disappear or be redirected. Treat improvements in utilization, win rate or margin as scenarios rather than guaranteed vendor benefits. The companion PSA guide explains the functional scope behind those outcomes.
Questions to put in every vendor quote
Ask what is included in onboarding, how many data imports are covered, which integrations are standard, what support response is contracted and how data can be exported. Confirm whether sandboxes, API access, storage, AI usage, additional entities and historical records create extra charges.
Request a written definition of “live.” A configured tenant is not the same as an adopted operating system. A useful milestone requires agreed data quality, trained process owners, a completed billing rehearsal and a successful reporting reconciliation.
Make the decision auditable
Score cost separately from functional fit, implementation risk, security and adoption. Keep the evidence used for every score: proposal version, demo scenario, reference answer and contract clause. This prevents the cheapest headline from dominating a decision whose largest costs often appear after signature.
Before approval, let finance test the TCO, operations test workflows, IT test architecture and end users test the pilot. The final recommendation should state assumptions and conditions, not pretend that one number predicts the future. Then carry those assumptions into the implementation checklist.
