Engagement brief

Source: article two, "Define the business process and proposed solution", "Make dependencies visible so somebody can resolve them", "Select an engagement that can test the practice", and "Establish the practice through a sequence of explicit commitments". Article three, "Refine the engagement brief before committing to a solution".

Who fills this in, and what it decides

The FDE lead writes it with the business workflow owner before discovery is authorised. Each named owner confirms the part that concerns them. The brief feeds the intake decision in section 5 and the first commitment in section 6. Article three returns to it at requirements refinement, when case walkthroughs may change the diagnosed problem or the proposed solution; record each revision against the version field in the header.

Roles named in this document:

Business workflow owner

owns the business process and the meaning of a useful result. In the specimen, the banking workflow owner.

FDE lead

owns delivery evidence for this engagement.

Practice lead

manages the FDE portfolio and capacity, and authorises practice-level commitments.

Data and control owner

decides whether source data may be used, and under which conditions.

Method owner

defines what counts as a valid result. In the specimen, the valuation or risk owner who defines a valid peer comparison.

Platform product owner

owns the shared AI primitives the solution uses.

Release authority

approves production use on technical, business, control, and operational evidence.

Service owner

accepts deployment, support, dependencies, and technical change after the engagement.

Two terms recur. The workflow is the business process the solution supports. The proposed solution is the change being tested; it may be an agent, a retrieval system, a conventional application, a process change, or another design, and it stays a proposal until the evidence in section 3 supports it.

1. The six fields

The table defines each field, who writes it, and the decision it feeds.

The worked specimen is the transaction-screening engagement from the article. It is hypothetical, and shows the precision each field needs.

Problem

Deal analysts spend substantial time collecting filings, research, and market data before deciding whether a potential transaction merits deeper work.

Supported cases

Potential acquisition targets in one sector at the initial screening stage, using approved public filings, internal research, market data, and early diligence documents.

Proposed result

A source-linked screening brief that extracts financial measures, compares selected peers, flags conflicts, and lists missing evidence.

Out of scope

Investment recommendation, valuation approval, trading instruction, client communication, and use of non-public data outside the approved deal team.

Main uncertainty

Whether the available sources contain consistent entity and period definitions for a brief that bankers can review faster without hiding exceptions.

Evidence for the next decision

Comparable manual effort, factual correction rate, source-access behaviour, reviewer acceptance, and the receiving team's ability to operate the solution.

Your brief:

Problem

Supported cases

Proposed result

Out of scope

Main uncertainty

Evidence for the next decision

2. The business process, step by step

A business process has a starting event, actions, decisions, exceptions, and users. Write it from case walkthroughs. A case walkthrough follows several completed cases from trigger to final decision and records each action, source, system, wait, exception, handoff, and decision, with the people who did the work. Formal procedures describe the intended process; walkthroughs show how staff perform it. The FDE lead records the steps and the business workflow owner confirms them.

Each step should produce one question the engineering team must answer. If a step produces no question, it is probably not a step.

The specimen process is hypothetical.

Your process:

The boundary must include the next handoff, because that is where the business result becomes visible. If the next person must reopen every source and rebuild the work, the solution has produced another document rather than reducing effort.

The last step inside scope

The person who uses the result at that step

What that person can now do that they could not before

The decision that stays with the business owner

3. Credible alternatives

The requested solution stays one proposal until this comparison is done. The FDE lead records what else could address the diagnosed problem and why the proposal was chosen over it. Inconsistent source data can make data preparation the stronger investment; consistent data with slow tracing of figures can make a source-linked brief the right one. A changed recommendation is progress when the evidence supports it.

Chosen proposal, and the evidence that supports it over the alternatives

4. Dependencies

A dependency is a condition held by another person or team that must be satisfied before the proposed solution can operate. Naming one tells the practice where progress can stop and who can change the condition. The FDE lead records each row; the decision owner named in it confirms the row.

Column definitions. Decision owner: the role that can change the condition. Required contribution: what that owner must supply. Consequence if unresolved: what the solution cannot do without it. Alternative design if refused: the narrower or different design that would still address the problem. Status: the current state of the condition.

The specimen rows are hypothetical. Naming a dependency does not make it available. It makes the unresolved condition explicit, so leaders can fund it, narrow the process, choose another design, or stop.

5. The intake gates

These five conditions are gates, not ingredients in a single score. A proposal with prohibited data access cannot compensate by claiming a large potential benefit. A proposal with no credible technical path cannot compensate with a senior sponsor. The role in the "Confirmed by" column answers for that gate; the practice lead records the result and it feeds the intake decision.

Any "no" stops the proposal here. Record what would change the answer, who can change it, and how large an investigation that would take.

A small discovery engagement can investigate uncertain extraction or data quality. It cannot investigate its way around prohibited access.

6. The first commitment

The first commitment authorises discovery. It commits the enterprise to answering a bounded question, not to a production launch before the evidence exists. The investment committee, or the accountable technology and business leaders, authorise it; the practice lead records it.

Business workflow owner

FDE lead

Platform participants

Control participants

Supported cases in discovery

Principal uncertainty

Budget, from the engagement allocation in the funding plan

Discovery ends on

Authorised by, and date

The evidence that discovery must produce before any further commitment. The decision rule says what result leads to which decision, so the outcome is not argued afterwards.

7. The commitment sequence

Each commitment is separate, with an evidence gate and a stop exit. At every gate, review the proposed solution and the delivery arrangement separately: a solution can produce useful proposals through an unsustainable amount of FDE intervention, and that is a finding about the arrangement, not the solution.

8. Agreement

Each role confirms that the brief describes their part and that the conditions it names are real. Agreement does not make a dependency available; it records who holds it.