Delivery diagnosis
Use this before proposing a team. It traces requests that stalled between a working platform capability and an operating business result, classifies what stopped each one, and turns the pattern into one decision: whether an internal FDE practice is the right response.
- Enterprise
- Prepared by
- Date
- Version
Source: article one, "When an enterprise should consider an internal FDE practice", and article two, "Start with a delivery problem, not a team design".
Who fills this in, and what it decides
The leader proposing the practice completes it, usually the platform leader or the prospective practice lead. The business owner named in each row confirms that row. The document feeds the decision recorded in section 7: establish a practice, fund the platform first, extend existing teams, engage a partner, or take no action.
The signal for a practice is not that business teams have many AI ideas. It is that platform capabilities exist, the workflows matter, and delivery repeatedly stalls on the connection between general software and local data, rules, systems, or operating responsibilities. This diagnosis tests whether that signal is present.
Terms used in this document:
- Shared platform
- the team and services that provide model access, retrieval, tool execution, controls, and evaluation support to every application.
- Primitive
- a capability the platform provides to several applications through a defined interface, such as permission-aware retrieval or document parsing.
- Delivery arrangement
- the path a request follows from a business problem through technical design, data and control decisions, release approval, and continuing service ownership.
- Service owner
- the role that accepts deployment, support, dependencies, and technical change for a released solution.
- Release authority
- the role that approves production use on technical, business, control, and operational evidence.
1. Trace the requests
Pick five to ten requests from the last year that mattered and did not reach normal operation. Include at least one that succeeded, so the comparison has a control. Answer every question with a named person or team. "Nobody" is a valid and important answer: it usually marks the point where delivery stopped.
The table defines what a complete answer contains. Record the answers in the register in section 3.
| Trace question | What a complete answer contains |
|---|---|
| Who requested it | The business owner with authority over the process, not the person who raised the ticket |
| Who built the pilot | The team, and the platform primitives it used |
| Who supplied data or system access | The data or control owner, and whether access was approved for this purpose |
| Who defined a valid result | The person who can say what counts as correct, and whether they had time to say it |
| Who could approve production use | The release authority, and the evidence it asked for |
| Who responds when a source or rule changes | The service owner, or "nobody" |
2. Classify what stopped each one
Use one class per request. If two apply, record the one that stopped work first and note the second in the register. The class matters because each one points to a different response, and only one of them is a case for an FDE practice.
| Class | What it looks like | What it implies |
|---|---|---|
| A. Missing shared primitive | The stop was a capability the platform should provide to everyone, such as permission-aware retrieval | Platform investment, not a delivery team |
| B. Nobody can own the connection | The capability exists and the data is available, but no team can spend time with the business to model exceptions, integrate, and build the review path | Delivery capacity across the business and technology boundary. This is the case an FDE practice addresses |
| C. The workflow does not remove enough effort | It reached production, then created so much review or correction work that people returned to the old process | Redefine the workflow or stop. More engineers will not help |
| D. An existing team could own it | A product or business-technology team already owns the process, the data, and the operation | Extend that team. An FDE handoff adds a boundary without removing the problem |
| E. Routine configuration or a demonstration | Standard setup, or a one-off executive demonstration | Route to platform support or enablement |
3. The register
One row per traced request. The person completing the diagnosis records it; the business owner named in the second column confirms the row. "Months stalled" counts from the first pilot to the date work stopped, or to today if it is still nominally active.
| Request | Requested by | Built by | Access supplied by | Valid result defined by | Production approval by | Change response by | Months stalled | Class |
|---|---|---|---|---|---|---|---|---|
| Transaction screening brief (specimen) | Coverage group head | Central AI team | Nobody: deal-room access not approved for this purpose | Nobody: the valuation owner had no time allocated | Not reached | Nobody | 7 | B, with an A component |
The specimen row is hypothetical. It shows the level of detail expected, not a measured case.
4. Read the pattern
The question is which class dominates, and whether it repeats across business units. Each pattern points to a different response.
- Mostly A
- fund the platform first. An FDE practice would spend its time waiting on the same primitive.
- Mostly B, in more than one business unit
- this is the case for an internal practice. Continue to section 5.
- Mostly C
- the workflows were badly chosen. Fix intake before adding capacity.
- Mostly D
- extend the existing teams and give them protected time.
- A single valuable B
- consider a bounded engagement, or one embedded engineer, before creating a function.
5. State the case
Each line needs evidence from the register, not an assertion. Name the confirming owner where one exists.
The case is stronger when each of these holds.
- Platform capabilities exist, named
- The stalled workflows matter, and the business owner can say what changes if they operate
- Delivery stalls on the connection rather than on a missing primitive
- The same pattern appears in several business units, named
The case is weaker when any of these is true.
- An established team already owns the workflow, the data, and the operation
- The work is routine configuration or a one-off demonstration
- The stop is a missing shared primitive that should be built centrally
The decisive condition, which article one states as the test:
- No existing team can own the complete result. Evidence
6. Which arrangement is being proposed
FDE is a function, not one organisational template. Article one describes four arrangements that companies use. Record which shape the enterprise is proposing, and why the diagnosis points to it. An internal practice usually takes one of the first two shapes. The third is a partner engagement. The fourth is how a product company organises the work, and it applies internally only when a platform team wants deployment lessons returned to its product.
| Shape | What the engagement includes | What ends it |
|---|---|---|
| Bounded integration | A defined result and the engineering to reach it | The agreed result is in operation |
| Complete application delivery | Workflow selection, build, and deployment with data, tools, and controls | A working system in the receiving team's hands |
| Specialist partner | Implementation depth and operators supplied by a separate firm | Contract terms. The enterprise must decide what it retains |
| Product plus deployment split | One customer's data, systems, and operating requirements, with lessons returning to the shared product | Does not end. Lessons return to the product |
- Proposed shape
- Why the diagnosis points to it
- What the enterprise must retain if a partner supplies the work
7. Decision
- Requests traced
- Dominant class
- Business units showing class B
- Decision
- establish a practice | fund the platform first | extend existing teams | bounded partner engagement | no action
- The repeated delivery problem, in one sentence
- Decided by, and date
- Next documents if a practice is established (engagement brief, authority map), owner