Build around what already works

A new project can change one part of your business while preserving the tools and routines that already serve the team. The useful question is what should stay, what needs to change and where the two will meet.

Keeping the existing system still leaves questions to answer. A team can depend on its current records, status names, permissions and habits in different ways. Naming those dependencies gives the build a clearer boundary.

Start with what the team relies on

Imagine a service business that tracks repair requests in an existing job system. The team knows how to assign work, update its status and find the previous conversation. Customers, however, send new requests by email, sometimes without enough detail to begin.

The business is considering a web form. The first discussion could focus on how a request enters the job system while preserving the way the team manages accepted jobs.

Useful things to record would include who uses the system, which information they need and which parts of the process they want to keep. A familiar tool may still have limitations. Preserving it is a choice to check against the changes you need.

Define the part we are adding

For this imagined project, the new part might collect the customer's contact details, the kind of repair requested and a description of the problem. The team would need to agree which details are required before a request can be reviewed.

The scope should also say what happens after submission. Does the form create a new request in the job system, or does someone review it first? Which existing field receives the repair type? Who decides how to handle a request that does not fit a known category?

Those choices determine more than the form's layout. They define the work connecting the customer's action to the team's next step.

Check where the two parts meet

Before agreeing on a connection, we would check what the existing system permits. That includes how it receives information, what access is available and whether its fields can hold the details the form collects.

The exception belongs in that discussion too. If the job system cannot accept a request, someone needs a way to notice and handle it. The customer also needs an accurate message about what happened.

If the proposed connection is not practical, the scope can change. A defined manual review step may be an option, or the team may need to reconsider part of the setup. The choice depends on the actual system and the work involved.

Agree what the team gets at handover

The handover should make the agreed responsibilities visible. In this example, the team would need to know where requests appear, how to correct a category and who handles a failed submission.

It would also need the appropriate access and instructions for the parts it is expected to manage. Any access that remains with an outside team should have a stated reason and an agreed owner.

Ongoing support is a separate conversation. Who handles questions, changes or a failed connection after handover? What work is included? These details need agreement for the particular project.

Put the boundary into a short scope note

For the imagined repair business, the starting note could read:

Your setup: Keep the current job system and the team's process for managing accepted work, subject to checking its limits.

Our part: Define and build the request form and the agreed route into that process.

The handover: Provide the access and instructions for receiving requests and handling the agreed exceptions.

Open decision: Confirm whether new requests enter the job system directly or wait for a person to review them.

That note gives us a shared starting point for discussing what to build and what remains to be decided. It makes the existing work part of the scope.

Write a short scope note for your project using Your setup, Our part and The handover, then name the connection or responsibility that still needs checking.

Prepared for WGMI with AI assistance.