Selecting a new capability
The organisation needs a system it does not yet operate, and the choice will shape process, integration and cost for years.
See supported situationsDecision Assessments
Run a defensible technology decision, end to end.
A Decision Assessment is the governed record and working environment for one material technology decision. PROVE structures the decision, connects requirements, evidence, options and stakeholders, records challenge and trade-offs, and preserves the approval and audit trail behind the outcome.
PROVE does not make the decision. The organisation does. The platform makes the reasoning visible, the evidence traceable and the approval defensible.
The object
What is a Decision Assessment?
A Decision Assessment is a governed record and working environment for one material technology decision. It is not a shortlist, a scorecard or a preferred-vendor slide. It is the place the decision lives while it is being made, and the place it is defended after it is approved.
It is distinct from a software recommendation. A recommendation answers what the organisation should choose. An assessment records why that answer was reached, what evidence supported it, what the alternatives were and who approved it.
- The decision question
- Organisational scope
- Stakeholders and decision owner
- Requirements and weighting
- Options under consideration
- Evidence attached to each requirement
- Recorded trade-offs and risks
- Recommendations with rationale
- Approvals and challenge
- Version and audit history
Trigger moments
When to start a Decision Assessment.
An assessment is worth opening when the decision is material enough to require a record. The trigger is usually one of the following.
Preparing or evaluating an RFP
A formal process needs consistent requirements, comparable responses and an evidence-linked evaluation the panel can defend.
See supported situationsRenewing an existing contract
A renewal is a decision, not an administrative task. The incumbent must be evaluated against current needs and credible alternatives.
See supported situationsReplacing an underperforming system
The incumbent is not delivering. The decision must record why replacement is justified and what a successor must do differently.
See supported situationsResponding to a board or executive question
A named executive has asked why a technology direction is being taken. The answer must be traceable to evidence, not to opinion.
Addressing a material compliance, integration or operational risk
A risk has surfaced that the current portfolio cannot absorb. The decision to change must be evidenced and approved on the record.
Participants
Who participates in a Decision Assessment.
Every assessment has one named decision owner. Beyond that, participation reflects the materiality of the decision and the organisational context in which it is being taken.
The roles below are common contributors. Not every role is required on every decision.
- Decision owner
- Named on the assessment. Accountable for scope, quality of the record and the final recommendation put forward for approval.
- Executive sponsor
- Owns the business outcome, resolves stakeholder conflict and signs the decision into the organisational record.
- Workplace or real-estate stakeholders
- Represent the operational context, the user population and the physical or portfolio consequences of the choice.
- IT
- Contributes architecture, integration, support-model and lifecycle constraints; validates technical feasibility.
- Security and privacy
- Sets non-negotiable controls, reviews vendor posture and confirms residency, processing and certification requirements.
- Procurement
- Governs commercial terms, competitive fairness and the record required for audit and challenge.
- Finance
- Owns total-cost, capital versus operating treatment and the assumptions used in scenario modelling.
- Operational users
- Represent the people who will use the system daily; their input tests whether the requirement set is real, not theoretical.
- Independent expert reviewer
- Where materiality warrants it, a qualified reviewer challenges reasoning, evidence and gaps before recommendation is finalised.
Requirements
How requirements are gathered.
Requirements are the specification against which options are evaluated. In PROVE they are treated as an organisational asset, not a document produced once and discarded.
Organisational, not generic
Requirements reflect the way this organisation works, its portfolio, its constraints and its obligations.
Prioritised and weighted
Must-have, should-have and nice-to-have are stated explicitly, with weights that force honest trade-offs.
Traceable to stakeholders
Each requirement is attributable to the person or function that owns it, so challenge and change are visible.
Reusable where appropriate
Corporate standards, security baselines and integration rules are drawn from a library rather than re-invented.
Versioned as the decision develops
Changes are recorded rather than overwritten, so the panel can see how the specification evolved.
Evaluation
How options are evaluated.
Options are evaluated against the same requirements, in the same units, with the same weights. Scoring gives the panel a common frame. It does not, on its own, decide the outcome.
A score is a summary of evidence. The evidence, the weighting and the human judgement behind them remain visible to approvers, so a numerical result never stands alone.
Like-for-like comparison
Options are compared against the same criteria in the same units, so the panel is not choosing between differently framed answers.
Requirement-level criteria
Each requirement carries its own criteria, so a strong overall score cannot hide a failure in a must-have area.
Weighting that reflects priority
Weights are visible on the record so approvers can test whether the priorities used match the priorities agreed.
Exclusions and dependencies
Where an option depends on another system, integration or condition, the dependency is recorded, not assumed.
Total cost and operational implications
Licence, implementation, integration, change and run costs are considered together, not as separate conversations.
Security, privacy, integration and commercial
Non-functional criteria are first-class inputs, not late-stage objections raised after a preference has formed.
Evidence linkage
How evidence is linked to requirements.
Evidence is attached to the specific parts of the decision it supports. Provenance, confidence and known limitations remain visible against every claim, so approvers can test the reasoning without leaving the record.
Requirements
Every requirement can carry evidence explaining what it means and why it matters.
Evaluation criteria
Each criterion is supported by the source that confirms how an option performs against it.
Vendor claims
Vendor-supplied statements are attached with their source, date and status so that verification is visible.
Risks
Each risk carries the evidence that identified it and the analysis that sized it.
Assumptions
Assumptions are recorded explicitly and linked to whatever backs them, so approvers can test them.
Recommendation rationale
The reasoning behind the recommendation is anchored to the specific evidence that supports it.
Trade-offs
How trade-offs are recorded.
No material decision is free of trade-offs. A Decision Assessment records them explicitly, so approvers know what the organisation is accepting and what it is declining.
Benefits accepted
The advantages the organisation is choosing to secure by making this decision.
Limitations accepted
The capabilities the chosen direction will not deliver, stated in plain language.
Risks retained
Risks the organisation is knowingly carrying, with owner, likelihood and mitigation on the record.
Conditions that must be met
The conditions under which the recommendation stands, and what changes if a condition fails.
Stakeholder objections
Objections raised during review, the response given and whether the objection was resolved.
Unresolved questions
Questions the panel could not close, retained openly rather than quietly dropped.
Reasons an option was excluded
For every excluded option, the reason for exclusion and the evidence that supports it.
Recommendation shape
How recommendations are justified.
A PROVE recommendation is not a single answer on a slide. It is a set of options with reasoning, so approvers can see the full shape of the decision, not only the preferred path. Every form of recommendation remains subject to human review and organisational approval.
Form
Recommended
The option the panel puts forward for approval, with rationale, evidence and conditions.
Form
Alternative
The credible second option, with the reasoning that would make it the right choice under different weightings.
Form
Conditional
An option that becomes viable if specific conditions are met or resolved before decision.
Form
Excluded
Options considered and set aside, with the reason for exclusion attached to the record.
Every form carries its own rationale, linked evidence, assumptions, risks, conditions and any dissent or challenge raised during review.
Approvals
How approvals are documented.
Approval is the point at which a recommendation becomes an organisational decision. It is recorded against the specific version of the recommendation that was approved, so the trail of reasoning survives later change.
- 01
Named approvers
The people whose approval the decision requires are declared before evaluation begins.
- 02
Approval status
Each approver's current status against the current version of the recommendation is visible on the record.
- 03
Comments and challenges
Approver comments and challenges are captured against the version they refer to.
- 04
Decision versions
Every material change to the recommendation is a new version, not a silent overwrite.
- 05
Superseded recommendations
Earlier recommendations are retained as superseded, so the trail of reasoning survives change.
- 06
Final approval date
The date the decision moved to approved is recorded against the version that was approved.
- 07
Retained audit trail
The full sequence — assessment, evidence, evaluation, challenge, approval — is preserved for later review.
The artefact
What a Proof Report contains.
The Proof Report is the exportable, board-ready expression of the Decision Assessment. It draws from the record. It does not replace it.
Report generation is assisted by the platform. The content, the rationale and the recommendation remain the responsibility of the people named on the decision.
- Executive summary
- Decision question
- Scope
- Stakeholder record
- Requirements
- Methodology
- Option comparison
- Evidence register
- Risks and assumptions
- Recommendation rationale
- Approvals
- Audit history
AI-assisted, human-accountable
Where AI helps, and where people remain responsible.
AI accelerates the mechanical work of building the record. It does not replace the people accountable for the decision.
AI may assist with
- Extraction from vendor and source documents
- Normalisation into comparable structure
- Evidence matching against requirements
- Comparison across options
- Discrepancy and inconsistency detection
- Gap identification in the evidence base
- Scenario and weighting modelling
- Drafting of narrative sections for human editing
Qualified people remain responsible for
- Organisational context and intent
- Interpretation of sources and materiality
- Trade-offs and what the organisation will accept
- Challenge of reasoning, evidence and gaps
- Stakeholder alignment and dissent
- Verification of the recommendation
- Approval on the organisational record
- Final accountability for the decision
The buyer outcome
A defensible decision is a record, not a preference.
A defensible technology decision is not merely a preferred option. It is a visible record of why that option was chosen, what evidence supported it, what risks were accepted and who approved it. That is what a Decision Assessment produces.