Purpose and method
This assessment is intended for IT providers who can design or deliver changes to business operations, rather than only install or configure a predefined software package.
The assessment reconstructs the client’s relevant revenue model, delivery obligations and operating decisions. For each consequential decision, I identify the required information and any documented responsibility or acceptance rule. I then compare those requirements with the supplied implementation scope and other system information legitimately available to me.
Each finding is labelled as externally evidenced, supplier-reported, inferred or not established. If the documents do not name a decision owner or operational system, I record that as unknown; I do not assume the business lacks either. A feature absent from the delivered project may already exist elsewhere.
Review procedure
- Define the delivered boundary. Record which processes, entities, events, integrations and reports the supplier’s completed project covers. Note which claims come from implementation documents and which are supplied descriptions.
- Model the economic and operating dependencies. Identify the revenue activities, delivery commitments, resource constraints and decisions that could materially affect cost, capacity, margin, risk or service quality. Mark inferred dependencies separately from observed facts.
- Identify the decision, ownership and evidence requirement. For each selected decision, ask what triggers it, who can make or reject it, what data are needed and where those data should originate. Where the operating rule or owner is not documented, record a validation question rather than concluding that governance is absent.
- Map existing coverage. Compare each decision and required event with the delivered system, known integrations, supplier-reported tools and potential manual controls. Classify coverage as documented, reported, outside the supplied scope or unknown.
- Test the intervention rationale. Retain a candidate only if the potential business consequence is material, existing support is plausibly inadequate or unverified, and a concrete client-side test can confirm or reject the need. Separate an operating-rule prerequisite from any technical work.
- Recommend next actions. Specify the first question for the account owner, the evidence to request, the condition that would close the candidate and whether the next step is operating clarification, technical discovery, monitoring or no further work.
Evidence labels: externally sourced; supplied by the IT provider; analyst inference; not established. This is a research classification, not a confidence percentage or an audit certificate.
Deliverables
| Output | Contents |
|---|---|
| Business Model Snapshot | Bounded model of relevant revenue, delivery and resource dependencies, with the operating decisions they imply. Each inference is labelled. |
| System Coverage Map | Decision, owner or owner-to-verify, required data/event, existing system coverage and unresolved questions. Unknown is not treated as absent. |
| Intervention Candidate Register | Candidates with economic relevance, decision ownership, evidence, possible technical fit, prerequisites and rejection conditions. No minimum number is promised. |
| Recommended next investigation | Order of questions for the supplier to put to the end client, proposed evidence to request, operating issues to settle first and conditions for stopping. |
Intervention Candidate
- Business dependency
- Which operating decision or customer obligation is affected, and how could it influence revenue, costs, capacity or risk? Potential impact is not stated as a measured result.
- Decision and authority
- What decision would change, which function would act, and who owns it — documented, reported or not established.
- Operating prerequisite
- Whether a process definition, acceptance rule, event-capture mechanism or accountable owner must be confirmed before technical design.
- Technical relevance
- Which class of system change might be appropriate if the client confirms the need, or why no build may be justified.
- Existing coverage
- What the delivered system is documented to support, what other systems are known or reported, and what remains outside the evidence supplied.
- Evidence status
- Source references, supplier-reported facts, inferences and material unknowns — including unknown decision ownership.
- Validation action
- Who the supplier should ask, which evidence would resolve the question, and what observation would reject the hypothesis.
- Recommendation
- Investigate, monitor, do not pursue or insufficient evidence. These are research decisions, not sales stages.
Included scope and exclusions
The standard scope covers one end-client company, relevant public sources, and one defined delivered project or documented system footprint. The supplier provides an implementation summary, known integrations and suitably authorised high-level data or process descriptions. Source records and system access are not required. Any additional project scope, end-client interviews, internal data review or detailed architecture work requires a separate agreement.
Decision ownership and economic impact are assessed only to the extent the evidence permits. Where internal authority, operational rules or financial effects cannot be established without the end client, the deliverable is a precisely framed question for the supplier to validate — not a finding that the client lacks a management process or is losing money.
No direct contact with the end client, live-system testing, implementation specification, build estimate, security assessment or guaranteed project is included. The supplier owns client contact and technical discovery. Conclusions identify the limits of the evidence; they are not an audit of all systems used by the business.
Read why a completed implementation may leave an operating decision unsupported →
Price and commissioning
£850 for the agreed assessment, including an outcome of no justified further technical work. After a £50 Screen for the same client, £800 remains payable. Exact documents, delivery date and permission to use supplied information are agreed in writing before work starts.