IBM Consulting announced the Forward Deployed Units (FDU) model on May 14, 2026: a delivery team composed of business experts, architecture and engineering roles, cooperating with the AI agent, and emphasizing continuous execution and customer participation after launch. FDU refers to delivery unit and cannot be confused with FDE individual position. The announcement is the company's own methodological statement and does not disclose the task lists and operating records of customer projects one by one.
An online project will continue to receive changes of different natures
Below are independent work designs that small teams can discuss. After a certain data query process is launched, customers may ask three things at the same time: the query that was originally available now reports an error, they want to adjust a classification rule, and they want to add new data sources. The three things are all called requirements, but the processing order, responsibilities and costs are different. If everything is directly inserted into development, it will be difficult for the team to judge whether the original service is being maintained or another project is started.
Changes can be divided into three categories: failure recovery, maintenance of established rules, and new scope. For faults, first confirm the affected users and alternative solutions; rule maintenance checks who can confirm the new scope; for new scopes, evaluate dependencies and workload. Classification is for the purpose of arranging work, and it is not appropriate to judge charges or responsibilities based on names alone. The specific boundary still needs to return to the service agreement that has been confirmed by both parties.
Continuous service requires scheduling capacity, not just retaining contacts
Small teams can start with actual support tickets from the most recent service cycle and record how much time was spent on temporary processing, which problems occurred repeatedly, and how long planned work was delayed. On this basis, clear capacity is reserved for fault handling. When there are insufficient records, you should first observe and do not use an industry average percentage to claim that all teams should reserve the same manpower.
If maintenance work continues to exceed capacity, you should check with the customer to see why: the data source is unstable, business rules change frequently, or the solution itself is still immature. Different reasons correspond to different treatments. Some need to repair components, some need to reduce the frequency of changes, and some should re-confirm the scope of the pilot. Writing recurring issues into a plan for the next cycle makes it easier to discuss than relying on the same person to put out fires temporarily over a long period of time.
The version currently in operation and the version under development must be compatible.
Continuous delivery does not mean that all changes enter the running system immediately. The team can reserve a clear number for the online version and associate pending changes to the target version. Emergency fixes first record what was actually changed; subsequent development must absorb this fix to avoid bringing back old problems in the next round of releases. These are the engineering arrangements proposed by ChinaOPC, not the IBM implementation details disclosed in the announcement.
Customer business personnel can also directly participate in change selection. For example, what daily operations will be changed by a new field, whether historical data needs to be supplemented, and who will use the results should be discussed before scheduling. The product of this joint engagement is a change statement that is understood by both parties, not just attending weekly meetings. AI can assist in organizing support tickets and related records, but priorities and business commitments still need to be decided by the responsible people.
Periodic review should be able to change the next round of work
When reviewing, you can compare the original plan, actual completed items and items squeezed out by temporary tasks for this cycle, and then list the repetitive work that needs to be reduced in the next round. If you can only report how many support tickets were processed but cannot explain which duplicate failures were eliminated, ongoing service may still be accumulating burden. Small teams can target one verifiable improvement for the next cycle without rushing to add more features.
IBM's FDU announcement provides clues to putting development and operations in the same delivery system. This article does not use its people efficiency promotion figures, nor does it identify IBM or the delivery team as OPC. When researching large service providers, it is more suitable to extract issues that can fall into your own work arrangements, and then use actual records to test whether they are applicable.
Extended reading: Maintenance capacity for solo entrepreneurship and How to choose the first collaborator, consider continuous service requirements and team capacity together.