FDE and SI delivery: who owns operations and adoption after acceptance?

When comparing FDE and systems integration, identify the work after acceptance rather than assuming one model only delivers software and another remains indefinitely. Release, quality acceptance, usage observation, exception correction and operations can be separate stages with different owners.

This guide focuses on those boundaries. FDE often describes engineering teams working closely with real usage contexts. Location, duration, fees and support obligations still need agreement for the actual engagement. Integration, consulting and engineering services can overlap; labels are not contracts.

Define evidence for each stage

Deployability does not establish accepted output quality, permissions, exceptions or workflow fit. Daily use does not establish correctness either. Each stage needs an owner, evidence and acceptance criteria.

GAO's 2021 AI accountability framework addresses governance, data, performance and monitoring across the lifecycle. It helps formulate questions, not prove that one provider category legally assumes every risk.

Do not prefill the table with “SI is not responsible” or “FDE includes everything.” Comparable scope requires the same questions for every bidder.

Separate adoption causes from responsibilities

In a hypothetical knowledge-query pilot, users might return to an old process because sources are inapplicable, answers do not support decisions, permissions are missing or the alternative is easier. The eligible task may also occur rarely. Usage counts alone cannot identify the cause.

Inspect quality, eligible opportunities, use and return records, and review burden together. Separate an in-scope defect from an additional requirement, data dependency or process decision. Assign each to its owner rather than attributing everything to one adoption measure.

A proposal can include joint observation and iteration, but needs a period, participants, budget and decision process. Working close to users helps understand workflows; it does not automatically include new features, unlimited adjustments or guaranteed outcomes.

Change control can support iteration

Agree which corrections are in scope and which require reassessment of cost, schedule, risk and acceptance. Retain version and decision records. An immediate adjustment should not become an unapproved permission or process change.

IBM's AI consulting description spans multiple build and transformation capabilities. Services need not follow a company-category boundary, but that description does not prove another proposal includes the same obligations. Each bidder must explain its own scope and evidence.

Handover needs demonstrated receiving capability

List what the receiving team must do: deploy, configure, test, monitor, handle incidents and perform necessary repairs. Observe those tasks during handover. Missing skills or time need an agreed remedy or continuing support; provider departure does not establish independent operation.

Check code, configuration, data, third-party components and documentation rights against actual contracts and licenses. A delivery label does not transfer all IP, risks or costs. Compare dependencies, customer effort, changes, support and exit costs alongside bids rather than assuming one model is cheaper or faster.

Decide with one acceptance checklist

Stable requirements may support a bounded stage; uncertain work may justify exploration or a pilot with stopping criteria. Decide from project evidence and available people, not predictions attached to Copilot, Agent or RAG labels.

Use the existing FDE/system-integrator proposal comparison for broader dimensions. Review Tenten's delivery method for first-stage and operating scope, then confirm obligations and acceptance in the actual proposal.