Creativity that creates value

From a clear question to a verified result.

I connect analytical thinking, context and clear communication.

A golden visual journey from analysis to improvement

How I work

Six connected steps

The process is not a straight line. New evidence often takes me back to a question, a refinement or another option. That is why the journey appears as a living line that gradually lights up.

⌕

Clarify the purpose

Understand the decision or need the output must support.

Ask precise questions

Clarify definitions, expectations and uncertainties.

◎

Describe the context

Connect requirements, data sources, process steps and responsibilities.

✦

Communicate findings

Separate established facts, assumptions, possible impacts and next steps.

✓

Verify actual behaviour

Compare expected and actual outcomes, including exceptions and boundary cases.

↗

Check the change

Return to the original requirement and check the result.

In Quality Assurance

test scenarios beyond standard happy paths
hidden relationships and unusual combinations
root causes rather than symptoms alone
clear communication of defects and risks

DATA

In analysis and processes

connecting user needs and technical solutions
simplifying workflows
verifying the data journey and actual impact
finding solutions within real constraints

TEXT

In communication

turning complex topics into clear structure
precise yet human wording
visual organisation of information
content that supports decisions

Research-informed practice

Eight ways to move a problem forward

The following methods extend my approach with published experience from IT teams, banking supervision and process improvement. Source-based principles and proposed practical applications are distinguished below; the external cases are not my own projects.

Understand the situation

Observe the problem where it happens

Design Council recommends learning from people affected by a problem. Toyota emphasises seeing the actual situation first-hand. Both can reveal a mismatch between the request and the underlying need. [5] [6]

Practical approach: follow one real task from start to finish. Note waiting, manual re-entry and workarounds. Separate a need such as faster decisions from a proposed solution such as another dashboard.

Output: a problem statement, the affected user and a measurable target.

From assumption to evidence

Test competing hypotheses

Google SRE describes troubleshooting as an iterative process of forming and testing hypotheses. Understanding expected system behaviour helps narrow the investigation; timing alone does not establish causation. [1]

Practical approach: for an incorrect report, examine source inputs, transformations and filters. Write down evidence that would support or reject each explanation. Start with a low-cost, low-risk test and record results.

Output: hypotheses, supporting evidence and remaining uncertainty.

Creativity with criteria

Compare alternatives before committing

The Double Diamond combines exploring possible answers with selecting and testing solutions. Defining the problem comes before deciding which change to implement. [5]

Practical approach: compare a process adjustment, a small system change and wider automation. Assess user benefit, effort, risk, dependencies and reversibility. Use the current process as a baseline.

Output: a reasoned choice, including disadvantages and conditions for success.

The complete data journey

Clarify definitions and ownership

Industry experience reported by the Basel Committee highlights continuing difficulties with data lineage, fragmented systems and responsibilities. Fixing one report may leave the broader data issue unresolved. [4]

Practical approach: trace a specific value from its origin through transformations to its use. Align the reference date, currency and population. Identify the business owner of the definition and the technical owner of the fix; record manual adjustments.

Output: a data map, validation points and an owner for each exception.

While the problem is live

Contain impact and coordinate the response

Google SRE recommends stabilising a service during a serious outage while preserving evidence for later investigation. Detailed diagnosis should not delay proportionate containment. [1]

Practical approach: identify affected services and customers, appoint a coordinator and agree an update rhythm. Consider limiting a feature, pausing a change or following a tested rollback procedure. Record decisions and their reasons.

Output: a shared incident status, temporary mitigation and a remediation plan.

Test small before scaling

Validate change under real conditions

IHI uses PDSA: plan a change, try it, study the result and adapt. Tests start small and expand through repeated cycles under different conditions. [7]

Practical approach: state the expected benefit and measurement method in advance. Test within a scope that protects the service. Alongside speed, monitor errors, support workload and effects on other teams.

Output: a before-and-after comparison, side effects and a decision to scale, adapt or stop.

Learn without blame

Turn incidents into specific improvements

Google SRE authors describe incident reviews focused on circumstances and system conditions. Shared records and completed actions create value; blaming someone for failing to predict everything does not. [2]

Practical approach: reconstruct a timeline together, including available information and failed controls. Give each action an owner, a deadline and an effectiveness check. Make it possible to report uncertainty while keeping responsibility for next steps clear.

Output: a concise review with verifiable actions and follow-up.

Make improvement last

Hand over to everyday operations

IHI distinguishes testing a change from making it part of routine work. Sustained improvement needs the supporting arrangements that keep the new process working. [7]

Practical approach: name a process owner, update instructions and check that another person can follow them. Agree a review date and warning signals. Ask users whether the change helped or merely shifted work elsewhere.

Output: an accepted handover, usable guidance and sustained-benefit measures.

Published experience

What real practice teaches us

IT · Google team experience

Automation needs boundaries

Google SRE describes an incident in which an empty list in automation caused unexpectedly broad effects. Actions taken afterwards reduced the impact of a later similar incident. [2]

Lesson: test empty-input semantics, safe repetition and limits on the scope of an operation.

Banking · the TSB case

Migrated data do not guarantee a working service

According to the PRA, TSB successfully migrated data in April 2018, but the new platform then experienced technical failures that disrupted customer access to banking services. [3]

Practical analytical inference: validate the whole customer journey, supplier dependencies and recovery readiness alongside data accuracy.

General practice · the IHI approach

An idea starts the work; testing creates learning

The Model for Improvement connects a clear aim, measures of benefit and repeated small tests. IHI uses this process-improvement approach in healthcare. [7]

Possible office application: try a new task handover format on a small number of cases, measure requests for missing information and expand only after learning. This is an illustrative application, not a claimed project experience.

A shared starting point

A short brief before choosing a solution

A single page can keep the technical team, business owner and users aligned. The prompts below are a proposed working aid.

Problem and impact: What should happen, what happens instead, and who is affected?
Evidence and uncertainty: What is observed, what is assumed, and what information is missing?
Alternatives and trade-offs: What options exist and what are their costs, benefits and risks?
Test and success criteria: What small test will distinguish the options and what result counts as success?
Decision and ownership: Who decides, who implements, and when do we stop or escalate?
Follow-up: When will we check the effect, side effects and operational handover?

Sources behind these ideas

Reviewed on 28 October 2026. These are published methods and experiences; they do not establish a claim that I delivered the cited projects. The Basel Committee newsletter describes implementation experience, not new supervisory requirements.