The project is delivered and the business does not change
A cross-functional artificial intelligence project can be technically successful and still change nothing. The model performs well, the interface works, the demonstration convinces, and six months later the people who were supposed to use it are doing what they did before. The reason is almost never the model. It is that the project was scoped as a system to be delivered rather than as a change to be sustained, and the work required to sustain it falls in the space between departments, where nobody holds a budget, a performance measure or a job.
Five mechanisms that fail at the boundary
These mechanisms are genuinely different from one another, and each has its own diagnostic. Treating them as one problem called alignment is why projects are misdiagnosed as technology problems and relaunched without change.
- Conflicting incentives. Each function is measured on its own number, and the improvement the project is built to deliver improves one of them at the expense of another. Procurement measured on unit cost and manufacturing measured on schedule stability pull in opposite directions on precisely the decisions the project requires to be made differently.
- Split data ownership. The records the project needs are owned by one function, the definitions that make them usable are owned by another, and neither will fund the work of reconciling them. The result is usually a duplicate extract maintained by a third party, which becomes the real system of record for the project.
- Unclear accountability. Nobody can say who is accountable for the outcome once the system is live. The delivery partner closes the project, the function's own targets are unchanged, and the process sits permanently between the two.
- Fragmented systems. The workflow crosses systems that were never built to exchange state, and the integration is funded as a one-off task rather than as a capability somebody maintains after the engagement ends.
- Poor handoffs. Work passes between teams with a different rhythm, a different definition of done and no shared state, so each handover reintroduces exactly the ambiguity the project was commissioned to remove.
The incentive layer is the one nobody changes
The first four mechanisms are uncomfortable, because each implies that somebody's current position is negotiable. The fifth is invisible, because incentives do not feel like mechanisms; they feel like context. They are also the one that determines whether the others can be remedied at all.
Boundary conditions and the decisions they require
| Boundary condition | Who is measured on it | What the project needs |
|---|---|---|
| A cost held by one function, a benefit earned by another | The cost function alone | Somebody to hold the net position |
| A data asset owned by a function with no mandate to expose it | The owning function's own metrics | An explicit and funded data obligation |
| A process with no single end-to-end outcome owner | Each function separately | One named owner of the result |
| A system boundary treated as a one-off integration | The technology budget of the year | A recurring maintenance line |
None of this can be resolved by the delivery team. These are decisions, and they have to be taken at executive level, which is why the executive sponsor's attention is the real dependency of the project. The organisational and process work that runs alongside the technology is described in business and organizational transformation.
Handoffs fail where the unit of work changes hands
A handoff is where ambiguity is cheapest to introduce and most expensive to detect, because the person receiving the work has no way of knowing what was assumed by the person sending it. Projects fail at handoffs for a specific reason: the project's definition of done is the sender's rather than the receiver's. Output has been produced, but nothing has been accepted.
The discipline that works is to define each handoff as an agreement with a named acceptor, a stated acceptance test, and a defined behaviour when acceptance fails. If the work cannot be accepted it must be returned, and returning it must be a normal and costless act rather than a confrontation. This is the same approval and exception machinery that any controlled automation requires, and the mechanics are described in designing AI workflows with approval and exception handling.
What to change before the next project starts
None of this argues against cross-functional projects. It argues for a different entry condition, and the condition is cheap to satisfy compared with the cost of a project that stalls after delivery.
- Identify the end-to-end outcome and name one executive accountable for it, with a number attached.
- Map the decisions the project changes, and check each one against the incentives that surround it.
- Obtain an explicit and funded data obligation for every shared record the project depends on.
- Define each interface as a contract with a named acceptor and an acceptance test.
- Agree who operates the integration after launch, and what the recurring cost of that operation is.
- State what happens to the old process, and who is responsible for removing it.
The question that predicts failure
There is one question worth asking at the start of every cross-functional project, and the answer predicts more than any technical assessment does: if this project succeeds, whose number gets worse? A project with no adverse effect on anybody's measure will not need cross-functional machinery at all, and a project that makes somebody's measure worse will fail there regardless of the quality of the model. Establishing baselines before the work begins is what allows that question to be answered with evidence, and the method is in calculating the value of enterprise AI. The organisational design that makes such projects durable belongs in designing an intelligent enterprise operating model.