Describe the problem before choosing the project.
“We need AI” does not yet define a useful piece of work. “Our team reads every quotation request, copies the requirements into a spreadsheet and then asks three people for missing information” is a more useful starting point.
The second description identifies a process, the people involved and the handoffs. It gives you something to examine before choosing a new tool or commissioning software. The aim is to find an intervention that changes the work in a worthwhile, testable way.
Start with one recent example. Follow it from arrival to completion. Note the applications, decisions and waiting points. Ask the person doing the task which parts are routine and which require judgment. This creates a concrete basis for comparing the options below.
Four options to consider.
| Option | Useful when | Main question |
|---|---|---|
| Configure an existing tool | The work fits an application you already have. | Can its current features meet the need? |
| Connect systems | The tools work, but information or actions must pass between them. | Which records and changes need to cross the boundary? |
| Add a workflow | The work involves several steps, inputs or decisions. | What should happen from the first input to the final outcome? |
| Build an application | The people doing the work need a dedicated interface or operational system. | What workspace does the team need to complete its tasks? |
These options can overlap. A small interface may sit above a workflow that connects existing tools. The important decision is where to begin and how much change the first useful outcome requires.
Check what already exists.
Ask the owner of your current application to demonstrate its relevant features against a real example. A setting, existing integration or better process configuration may address the problem. Include the effort needed to introduce the change to the team.
When an existing feature covers the work adequately, custom development may add little value. Record the gaps that remain. A specific gap is easier to scope than general dissatisfaction with a tool.
Separate missing connections from missing process.
If people copy the same information between otherwise suitable systems, investigate the connection. Establish which application owns the record, how it is identified elsewhere and what should happen if the information differs.
If the work also requires interpretation, checking, review and follow-up, describe the whole sequence. A connection may move data successfully while leaving the coordination work untouched. The scope needs to account for the outcome the team actually needs.
For example, an incoming document could require extracting information, comparing it with an existing record and preparing material for a reviewer. That is an illustrative design, not a claim that every document needs those steps. Your examples determine which steps are necessary.
Build an interface when the task calls for one.
Consider a new application when the team lacks a workable way to see and manage the process. Describe the tasks the interface must support: finding a record, understanding its status, reviewing information or taking the next action.
A custom application also creates responsibilities. Discuss who maintains it, how changes are requested, where data is held and how the team will receive support. Include those responsibilities in the comparison with extending existing software.
A useful first-project brief
- One process and its owner.
- Representative inputs and examples of acceptable outcomes.
- The systems and people involved.
- The main exceptions and review responsibilities.
- A baseline for the current work.
- Clear criteria for deciding whether to continue.
Evaluate a complete slice of work.
Choose a first scope with a visible beginning and end. An extraction demonstration can establish whether information can be identified. An operational trial needs to show whether the result helps the next person or system do its job.
Decide in advance what you will observe. Depending on the process, this might include time spent handling a case, the proportion requiring correction, missed information or the quality of the final record. Use real examples and document the conditions. Avoid treating a smooth demonstration as evidence for every possible input.
What ECH02 brings to that decision.
We work across document workflows, connected systems and business applications. Our engine, composer and reusable components give us a foundation to assess against the process.
The first useful question is which parts of your work need to change. From there, we can explain what already exists, what needs adapting and what new implementation would involve.