Establish a fair baseline.
Select a recent period and representative tasks: maintenance, reports, workflow changes, or integrations. Record what was accepted, what remained unfinished, and the quality and release requirements.
Use actual invoices and recorded time where available. Separate project delivery from incident cover, infrastructure, and other services bundled into your current provider’s fee.
Count each part of the new arrangement.
- Initial costs
- Discovery, environment repairs, access setup, training, and pilot onboarding. Show these in full, and separately show any amortization period used for an ongoing comparison.
- Recurring and metered costs
- The workspace, model or executor usage, and incremental hosting. Separate commitments from usage that changes with workload.
- Human effort
- The project owner’s direction and acceptance time, technical review, operating support, and release work.
- Corrections and incidents
- Rework, regressions, failed attempts, and investigation. Include time spent after a task first appears complete.
Measure outcomes that mean something.
For a report, check that it reconciles against known data and helps the team make the intended decision. For a workflow change, check that people can complete the task and that surrounding behavior still works.
Track turnaround from a ready request to acceptance, review delays, defects, and manager effort. A task count is only comparable when scope and quality are similar. Lines of code do not establish business output.
Keep a simple pilot record.
For each task, record the request, acceptance criteria, start and acceptance dates, result link, costs, project-owner time, reviewer time, revisions, and later defects. Record why tasks stall or stop.
At the end, compare like-for-like work and show uncertainty. A small pilot can help decide what to try next; it does not establish a universal saving.