Write a two-page decision charter before inviting demonstrations. The purpose is to distinguish a software problem from a process, data or staffing problem.
What should the charter contain?
Use these fields:
- Trigger: examination finding, control deficiency, renewal, acquisition, reporting requirement or operational bottleneck.
- Current failure: a specific activity that does not work adequately.
- Affected population: entities, functions, users and records.
- First outcome: what should be demonstrably different after release one.
- Decision deadline: including the reason it is fixed.
- Alternatives: retain, repair, configure, buy or build.
- Sponsor and decision rights: who resolves conflicting requirements.
- Funding boundary: selection, delivery and ongoing operation.
- Exclusions: work explicitly outside the first release.
- Success evidence: the report, transaction or completed process that will prove usefulness.
A good first outcome is specific: A control owner can submit evidence, a reviewer can challenge it, a failed test creates an accountable action, and the committee report traces back to those records.
An insufficient outcome is: Create a single source of truth.
How do you establish a baseline?
Measure the existing workflow before changing it. Suggested measures include:
- Time spent requesting and chasing evidence.
- Elapsed time from submission to review.
- Records without an accountable owner.
- Actions overdue under the current policy.
- Time required to reproduce the committee report.
- Requests that need manual reconciliation between systems.
- Costs of retained tools and external support.
Define the denominator and observation period. Separate labour capacity from avoidable expenditure: a reduction in task time is not a payroll saving unless finance identifies an actual cash consequence.
Exit gate: the sponsor can explain the problem, the first outcome, the alternatives and the person responsible for operating the result.