A useful scope is large enough to solve the problem and clear enough to take responsibility for. Sometimes that means one recurring task. Sometimes the difficulty sits between teams, or requires an application people can use. Start by locating the work, then choose the boundary.
What to take away
- A workflow is useful when one defined task has a clear start, finish and owner.
- A connected department makes sense when the problem spans several dependent handoffs.
- A custom application adds a working interface; its usefulness depends on the operation behind it.
Find where the problem actually lives
An owner might ask for better follow-up when the deeper difficulty is that nobody knows which jobs are ready to quote. Another might ask for a new dashboard when the numbers mean different things in different departments. Both requests are reasonable starting points. Neither should become a build specification without examining the work around it.
Describe the result you need in ordinary language. For example: an approved request reaches the right person with enough information to act. Then identify what prevents that result today. This helps distinguish a missing task, a broken handoff and a missing place for people to do their work.
Choose one workflow when the boundary is clear
A workflow is a connected sequence of work with a recognizable beginning and end. Consider preparing follow-up for eligible quotes, sorting incoming documents for review, or assembling an owner’s operating brief. These examples can be scoped around a defined input, result and exception path.
A focused implementation is especially useful when someone owns the work and can judge whether the result is right. It gives the business a concrete change to assess. Keep the boundary honest: if the workflow depends on cleaning up several other systems first, those dependencies belong in the conversation rather than outside the proposal.
Connect a department when the handoffs are the problem
Some problems cannot be resolved at a single step. An incoming enquiry may pass through qualification, quoting, scheduling and service. Improving only the first response may expose the next delay. A broader scope can be appropriate when the value depends on those steps sharing reliable information and clear responsibility.
That does not require changing everything at once. Agree how the pieces fit, then establish a sequence your team can absorb. Each stage should have a useful result and a person able to review it. A connected plan should reduce confusion about responsibility, not make it harder to tell which part needs attention.
Build an application when people need a place to work
A custom application provides an interface for staff, customers or partners. It might be a portal for submitting information, a mobile tool used during a physical task, or an operating screen that brings several activities together. AI may help inside that application, but the application has responsibilities beyond producing an answer.
People still need to understand what they can do, which information is current and how to correct a mistake. Access, records and the relationship to existing business systems matter. An attractive screen is useful only when the underlying work supports what the screen appears to promise.
Compare responsibility as well as capability
A larger scope brings more people, information and dependencies into the work. That may be justified, but it should be visible. Ask who will make decisions, who will review the result and what happens when a connected system is unavailable. Include adoption: somebody must use the changed process for it to matter.
NIST’s Map guidance emphasizes understanding intended use, context and affected people before proceeding with AI. Applied to scope, the principle is practical: a proposal should be specific about the environment in which it is expected to work. A successful demonstration in an ideal example is not the same as readiness for your whole operation.
Choose a scope you can explain and evaluate
At ProcessRoot, work can range from an individual workflow to connected agents and custom applications. The right starting point depends on the operating problem and the conditions around it. Breadth is useful when the need calls for it; a catalogue of possible features is not a reason to include them all.
Before approving a scope, try describing it to the person who will live with the change. They should understand what becomes easier, what stays theirs and how they will ask for help. If that conversation raises unanswered questions, resolve them before adding more features.
- What will be different when this scope is working?
- Where does the implementation start and stop?
- Which existing tools and people does it depend on?
- What can we evaluate before expanding?
- Who manages the system and future changes?
Common questions
Is starting with one workflow always better?
No. It is useful when it addresses a meaningful problem on its own. If the problem spans dependent handoffs, a broader plan may be more appropriate.
Does a custom application replace our existing software?
Not necessarily. It can connect to tools you already use. The scope should explain which system holds each important record and which responsibilities change.
Sources & further reading
Make it useful for your business.
Bring us the task that keeps getting in the way. We will help you understand what could change, what should stay with your team, and whether the work is worth doing.
Talk about your business
