Consider a hypothetical example: a company launches a system for employees to request expense reimbursements. The team delivers what was agreed, the tests pass and the project is closed. The developers move on to other work. Later, requests start coming back to the people who sent them because information is missing, and the finance team keeps sorting out the gaps by email.
The system works, but it has not yet reduced the work of checking requests. There may be a confusing instruction, a poorly chosen field or a rule nobody noticed during testing. To find out, someone needs to follow the returned requests and talk to the people who tried to use it.
Who will do that now? If the team has already been reassigned and support can only fix defects, a small change may depend on another project's approval. The company paid for the delivery but left nobody responsible for checking that it solved the problem.
What is still unknown after delivery
The deadline and the feature list help organize the work. In the reimbursement example, they make it possible to check that a receipt can be attached, an expense approved and the payment recorded. Those checks are necessary to put the system into use.
What remains unknown is whether employees can do all of that without asking for help. A request can go through every screen and still reach finance incomplete. In that case, counting how many requests were submitted says little about the work the tool was supposed to save.
It would be more useful to examine which requests come back for correction and why. Perhaps the same information is missing from many of them. The team could adjust the instruction for that field and watch the following requests. If returns continued, it would have a reason to look for another cause, instead of treating the task as done because the screen changed.
In Products Over Projects, published in 2018 on Martin Fowler's site, Sriram Narayan argues for teams that stay attached to the problem after delivering the software. He distinguishes funding a predefined solution from keeping a team able to check the results and revise what it built.
Applied to the example, that proposal means setting aside time to follow the reimbursement flow after launch. It also means deciding who can pause a new feature to deal with a difficulty that appeared in use. Without that agreement, even a team that knows the system well may have no room to improve it.
Whoever follows the system needs to be able to change it
Making someone responsible for the system only helps if that person or team can act on the problems they find. Receiving complaints, without the time or the authority to change the software, tends to turn that responsibility into a queue of requests.
In the reimbursement case, suppose the requirement for a certain document is causing the returns. The developer can change the screen but needs to understand, together with finance, whether that document is mandatory in every situation. The change depends on a decision about the process, not only on programming work.
That is why the agreement between areas needs to be specific. Who can revise the requirement? Who checks whether the change worked? If finance changes a rule, how will the development team find out? These details determine whether a complaint can be solved or merely forwarded.
The team maintaining the system should also be able to see why requests are returned, with access limited to the data it needs. Asking it to improve the process without letting it see where the process fails leaves the investigation dependent on incomplete reports.
This has a cost that needs to show up in planning. The hours spent following requests and fixing the flow are no longer available for other deliveries. Leadership needs to decide whether the reduction in finance's workload justifies that commitment, instead of expecting the team to do both within the same deadline.
Handing over to another team takes time
Keeping a team responsible for a system does not require keeping the same people indefinitely. People change roles, vendors end contracts and products come to need less development. Continuity depends on how responsibility is transferred during those changes.
If another team takes over the reimbursement system, the documentation can explain the approval rules and how to release a change. To take on the work, however, the new team also needs to know the problems that are still open. It is worth walking through a returned request with the person who investigated it, reviewing the existing tests and agreeing on whom to ask when a question comes up.
That handover takes time from both teams. Leaving it to the last day of the contract reduces the chance of noticing what is missing. A problem found later may require tracking down someone who has already left to understand an old decision.
There are also stable systems that do not justify a dedicated team. A shared team can look after them, as long as it has the capacity to handle the requests and it is clear how those requests will be prioritized. The size of the team can change with the work; support should not depend on finding someone willing to help by chance.
Before the project is closed, this arrangement needs to be agreed. In the reimbursement example, that would mean naming who will review returned requests after launch and where the time to fix what they find will come from. If nobody can take on that work, the decision to reassign the whole team still needs to be reconsidered.
