MEASURING IMPACT WITHOUT PROMISES
MEASURE BEFORE DRAWING A CONCLUSION.
Change projects sometimes rely on numbers stated before the work begins. A result announced before any measurement is a hypothesis, not a finding. Another approach starts by measuring.
AN ESTIMATE IS NOT A RESULT.
A decision often needs a calculation before the work begins. We separate what is known from what is assumed and examine when a change is likely to be worth the cost and effort.
An estimate is not a result. What actually changes is measured against the starting point.
THE BASELINE COMES FIRST
Before any change, the current state is recorded: cycle times, error rates, effort, inquiries, or other measures relevant to the bottleneck.
That baseline is the yardstick. Every later number is compared with it, not with a hope.
FEW METRICS, BUT USEFUL ONES
Not twenty charts, but three to five measures that make the bottleneck and its development visible.
A metric is useful when someone understands it, someone is responsible for it, and a decision depends on it. The rest risks adding noise.
THE MONTHLY ONE-PAGER
Once a month, one page: the metrics compared with the baseline, what moved, what did not, and what follows from it.
No dashboard graveyard and no reporting for its own sake. One page that prepares a decision.
SAYING NO IS ALSO A RESULT
If the measurement shows that an action does not produce the expected result, it is stopped rather than talked up. Avoiding unnecessary spending is also a result.
Honest measurement makes progress and the absence of effect visible.
MEASURE THE SERVICE, NOT ONLY THE RESPONSE TIME
A fast first reply does not show whether the issue was resolved or whether the business is better supported. Technical completion and business effect are two different levels.
Measure only what leads to a decision. Response time can matter. Resolution, recurring incidents, documentation, and the effect on daily work may matter more.
RELATED PERSPECTIVES
COMMON QUESTIONS.
Can DD estimate the return before we decide?
Yes, once we have a useful starting point. We compare the likely benefit with the cost and effort involved. Assumptions and uncertainties stay visible, and we use a range where a single figure would be misleading. It is a basis for a decision, not a guaranteed return. After implementation, we measure what actually changed.
Which metrics are the right ones?
The ones that make the identified bottleneck visible. Cycle times need different measures than inquiries or error rates. Keep the set small, make sure the team understands each metric, and assign an owner to each one.
How quickly does impact show?
Some things move in weeks, while others need months. Comparison with the baseline shows what is changing, including when something does not work.
What response times do we actually need?
The answer follows the affected work. A failure that stops invoicing or payroll needs a different response from a minor display issue. Define the consequence first, then set the response, escalation, and fallback the business actually requires.
How do we assess our IT provider’s performance?
Compare the agreed service with the actual record: availability where it matters, response and resolution, recurring incidents, quality of documentation, planned changes, and the effect on daily work. A service level shows technical delivery. It does not by itself show whether the business is better supported.
RECORD YOUR OWN STARTING POINT.
The diagnosis shows which measures make the bottleneck visible and establishes the baseline for later comparison. Then you decide.
In our first conversation, we clarify what you need and how to begin. If you need an overview first, we continue with a 60-minute diagnosis and a 48-hour deep scan. The Strategic Map is yours to keep. All of this comes without a fee. Then you decide. If you want to think through an idea or a decision, we start directly with consulting, once or on an ongoing basis. If your project is already clear, we agree scope, responsibility and price or a cost limit directly.
OTHER AREAS