Define the outcome before the solution.
Start with what you are trying to achieve, who is affected and how the work happens today.
Consider the constraints that shape a realistic answer: information access, procurement, budget, existing systems, internal capability and risk.
What would make this work useful?
Compare choices, not just products.
Explore what can be improved through process changes, existing capabilities, new technology or a combination.
Record assumptions and trade-offs so that the recommendation can be understood and challenged.
What needs to be true for this option to succeed?
Use evidence to reduce uncertainty.
A workshop, technical investigation or prototype should answer specific questions.
Agree what is being tested and what would count as a useful result. Record failures and limitations alongside the promising parts.
What have we learned—and what remains uncertain?
Make the recommendation usable.
Set out the decision, scope, ownership and practical next actions.
Where delivery proceeds, clarify what still needs production engineering, security review, user testing, operational support or specialist advice.
Who needs to do what next?
Working principles
- Problem before platform. Start with the need, not a preferred product.
- Evidence before scale. Test the assumptions that could change the decision.
- People remain accountable. Make review and responsibility explicit.
- Documentation is part of delivery. Keep reasoning and implementation knowledge usable.
- Scope should stay honest. Separate prototypes, pilots and supported services.
- Commercial reality matters. Consider cost, procurement and ongoing ownership.
What clients can expect
Direct communication with Shane, clearly scoped work and recommendations that distinguish evidence from assumption.
If an issue needs expertise outside the engagement, that boundary will be made clear.