Define the problem before evaluating tools.
Record the affected system, decision owner, constraints, success criteria and excluded scope before comparing products or architectures.
Principles
A commitment with no price is a slogan.
Not a slogan. It decides what work I take, how it is scoped, and when an engagement is finished. Each one costs me something, which is the only reason to trust any of them.
The commitments
What I commit to, and what each costs
Anyone can claim the commitment. The price is what turns it into one.
- 01
I fix, not just find.
An assessment that ends at discovery has moved the problem, not reduced it. A finding is finished when it is closed or deliberately accepted with the reason recorded — not when it appears in a register.
What it costsIt means quoting implementation, which is harder to scope than a report.
- 02
I stay until the work holds.
Through the implementation, the retest, and the awkward part where a planned change needs downtime agreed around someone else’s schedule. The alternative is a handover document and a list that comes back next year.
What it costsEngagements run longer than a report would, and cost more.
- 03
I name the actual problem, not the category it belongs to.
Two hundred findings are usually a handful of causes counted many times. Categories are easy to report and impossible to act on; causes have owners.
What it costsIt sometimes means saying the problem is not the one you were asked about.
- 04
I have no stake in what you choose.
No commission for recommending a cloud, a platform or a product, and no reseller margin anywhere. Where I would also deliver the work, that is stated in the proposal rather than discovered later.
What it costsIt rules out the revenue that makes cheap advice possible.
- 05
Selective by design.
I take work I can carry properly and decline work I cannot. Capacity is not a limitation to apologise for — it is the mechanism that keeps the work serious.
What it costsAvailability is confirmed before a proposal, and sometimes the answer is no.
Why it matters
A report is not a result
Discovery is the cheap half. The expensive half is the sequence, the owners, the downtime negotiated around a production schedule, and the evidence that still holds when someone competent asks about it a year later. That is the half most engagements skip, and it is the half that decides whether the same list comes back.
Method
How a recommendation gets made
A commitment is only worth stating if it can be checked. This is what is done, in order, on every engagement.
Separate root causes from symptoms.
Trace recurring findings and delivery failures to architecture, ownership, operating process or capacity before creating implementation tasks.
Record options, trade-offs and decision conditions.
A recommendation lists viable alternatives, rejected options, cost and operating assumptions, material risks and conditions for approval.
Disclose vendor and delivery interests.
No commission is received for recommending a cloud, platform or software product. Any delivery role is stated in the proposal.
Test the recommendation against implementation.
Confirm accountable owners, dependencies, acceptance criteria, evidence requirements and the first implementation sequence before handover.
Decision record
What a completed recommendation contains
- 01
Problem statement and scope
- 02
Evidence and unresolved assumptions
- 03
Options and evaluation criteria
- 04
Recommendation and rejected alternatives
- 05
Risks and approval conditions
- 06
Owners, actions and acceptance criteria
Next step
Hold me to it on a real decision
Bring the situation, the affected system, who owns the outcome and the deadline.
Book 30 minutes↗