From strategy to execution: decisions, ownership and evidence

Name the outcome before the activities

A strategy can become a long list of projects without making clear what should be different for customers, staff or the organisation. Describe the outcome in terms the people doing the work can recognise. Then identify the choices and changes needed, including what the organisation will stop doing.

If the aim is a more dependable onboarding process, launching a new form is an activity, not the outcome. Discuss the information needed, the decisions being made and the points where people wait. Distinguish useful work from activity that is easy to report but has little effect on the intended result.

Make ownership and decisions clear

Assign responsibility for moving each priority forward and specify which decisions that person can make. Record dependencies involving another team, supplier or governing body. Make the escalation route visible when a decision exceeds the agreed authority, rather than leaving the issue inside a general status report.

The UK's GovS 002 Project Delivery standard provides a public reference for governance, roles, planning and control in government projects. The working record below adapts those broad management themes. The government standard is not presented here as a mandatory requirement for private businesses.

Keep a small, useful working record

A practical record can contain the outcome, responsible owner, next milestone, dependency and decision needed. Add information that helps people act and remove fields that repeat another report. A concise record is useful only if the people responsible keep it current and use it to resolve issues.

Do not confuse a green status with a verified result. Ask what evidence supports the status and whether a dependency could change it. When a milestone slips, discuss the consequence for the outcome and the decision required now. Keep the record connected to delivery.

Use the review rhythm to make decisions

Structure reviews around what changed, what needs a decision and what is preventing the next step. Circulate routine updates beforehand where practical. Capture the decision, who will act on it and when the result will be checked. The cadence should suit the work rather than become another fixed meeting by default.

Return periodically to the original outcome. Ask whether the work is having the intended effect, assumptions still hold and priorities need to change. Stopping or revising work can be as useful as starting an initiative. Progress comes from clearer choices and evidence, not the size of the activity list.

Apply the delivery record to a finance-system change

A finance change is a useful application of the same execution discipline. Define the process, entity, system version and decision the change should improve. Map inputs, interfaces, manual adjustments and outputs. An automated report can still mislead if its export covers the wrong period or loses an approval history. Describe the observable outcome before treating installation as completion.

Assign ownership of transactions crossing the cutover. Keep a known source version, explain account mappings and reconcile opening balances, unpaid items and necessary history. Matching totals alone may miss an invoice assigned to the wrong supplier or currency. Record exceptions, their resolution and the point at which the new process can be relied upon.

The two original records below are practical execution aids, not a security certification or regulatory checklist. Scale the evidence to the consequence of an error and involve suitable specialists. They apply the strategy article to one finance-process change rather than prescribing a separate transformation programme.

Specify the evidence before relying on the change

Identify who can change sensitive data, who challenges the change and which evidence links it to an authorised decision. Where a small team cannot separate every task, assess the exposure and agree a meaningful additional review. A second click by the same account is not independent challenge. Use appropriate non-production records to test normal, rejected and repeated transactions.

A passing application test does not prove an accepted payment or filing. A successful backup job does not demonstrate a restore. Check uncertain connected outcomes at the authoritative destination before retrying. If an AI tool proposes a classification or summary, compare it with the source before acceptance and protect confidential data under an assessed arrangement.

Make approval to rely a recorded decision

Record actual readiness evidence and unresolved risks against the exact release. Keep technical completion, approval to rely and the first operational cycle separate. Conditions and pending decisions should stay visible. Reconcile the first cycle and review exceptions before declaring the intended outcome achieved.

Fictional illustration: invoice-to-ledger automation creates entries in a test, but a repeated import could duplicate them and nobody owns the exception queue. The delivery owner records both questions and requests evidence before reliance. This example claims no client deployment, vendor performance or financial saving.

MFSA's April 2026 ICT-change discussion concerns financial entities within DORA scope. It provides bounded regulated-sector context, not a universal obligation for finance teams. Obtain a separate applicability assessment where relevant. MTCA service guidance also distinguishes authorised filing roles: technology access alone should not be assumed to establish permission to submit for an entity.

Actions to consider

• Describe the observable outcome for each priority.
• Confirm responsibility, authority and important dependencies.
• Keep one concise record of the next milestone and decision needed.
• Use reviews to resolve blockers and reassess the outcome.
• For a finance change, record migration, exception and recovery evidence before the actual reliance decision.