Skip to content

What you get

Real documents, not invented case studies.

The work should leave you with a clearer record - not just a series of meetings.

What each document does for you

Documents leadership can actually use.

These are typical examples. What you actually get depends on the agreed scope - not every engagement includes every item below.

01

Decision brief

A choice you can look back on.

Useful when a specific decision needs a lasting record instead of another meeting recap.

ContainsThe question, context, constraints, criteria, options, trade-offs, recommendation, owner, and review point.

02

Roadmap view

A sequence with the reasoning attached.

Useful when projects are competing and leadership needs to understand why one comes before another.

ContainsCurrent picture, priority logic, dependencies, capacity, project briefs, and what would change it.

03

Vendor comparison

A comparison that goes beyond the feature list.

Useful when vendor claims need to be checked against how your organization actually runs.

ContainsBusiness fit, who's responsible for what, workload, cost, and open questions.

04

Steering summary

A short, readable update.

Useful when leadership wants a regular, concise view of what changed and what needs attention.

ContainsWhat moved, exceptions, decisions needed, ownership, and what to focus on next.

Our bar for a good document

One record. Three audiences.

Leadership should understand why the decision matters. The delivery team should see what happens next. Anyone reviewing it later should understand the assumptions and what would justify revisiting it.

The question we ask

What needs to be clearer once the work is done?

Who uses each document

Written once, useful for deciding, delivering, and reviewing.

A good document doesn't paper over uncertainty. It separates confirmed facts, assumptions, open questions, decisions, and actions, so people reading it later know exactly what changed.

Leadership

Why, and who decides

Outcome, options, trade-offs, recommendation, authority, and the risk decision.

Delivery

What happens next

Scope, dependencies, who's involved, checkpoints, and what counts as done.

Operations

What stays owned

Administration, support path, vendor responsibility, exceptions, and review point.

Keeping it current

We update the record when the decision changes - not to look busy.

i.Brief

Closed once authority and ownership are clear

Done when the recommendation is accepted, rejected, or deferred, with an owner and a review point on record.

ii.Roadmap

Reviewed at checkpoints and when things change

Updated when dependencies, obligations, capacity, funding, or business direction change the sequence.

iii.Steering summary

Kept short and focused on exceptions

Keeps what moved, decisions needed, ownership, and changed assumptions; drops status updates nobody needs to act on.

These are representative examples, not client work. What you actually get, how often it's updated, who owns it, and when it wraps up are all agreed in scope.

See which document fits which kind of decision