A request for new software usually begins with a real problem. A team may be re-entering the same information, correcting invoices, rebuilding reports, or relying on one person to remember what happens next.
The problem is real. The proposed solution may still be premature.
People describe the part of the work they can see. A salesperson sees an approval delay. Operations sees incomplete order information. Accounting sees a revenue correction. Customer support sees that access does not match the agreement. Each person may accurately describe a problem without being able to see the complete business result.
That is why the first step is not a product demonstration. It is learning how the work is actually performed.
Begin with the event that starts the work
Ask what happens immediately before the reported problem. Then keep moving backward until you find the business event or decision that begins the process.
A billing error, for example, may begin with the way an offering was defined, the terms approved in a contract, or a change made after the sale. Fixing the invoice screen will not correct information that was already incomplete when billing received it.
The same principle applies to employee, purchasing, and financial processes. A local problem may be evidence of an earlier decision, an unclear handoff, or information that no system is clearly responsible for maintaining.
Learn from the people doing the work
The people performing the work know where the formal process and the actual process differ. They know which spreadsheet compensates for a system limitation, which report must be checked by hand, and which customer situation does not fit the normal path.
Do not ask only what the new software should do. Ask:
- What information do you receive before you can begin?
- Which decisions are yours to make?
- Where does responsibility change?
- What do you do when the expected event does not occur?
- Which corrections can you make, and which require another department?
- How do you know the work is complete?
These questions reveal requirements that a feature list will not.
Follow the handoffs
Work often fails between departments, not within them. One team completes its task, but the next team does not receive the information, authority, or context it needs.
That handoff may pass through software, email, a shared document, or a conversation. The method matters less than the result: the next person must receive reliable information at the time it is needed.
Before selecting software, identify every important handoff and decide what must cross it. If the organization has not made that decision, automation will move the uncertainty faster.
Include exceptions before they become production surprises
The normal path is usually the easiest part to demonstrate. The difficult work appears when an order changes, an approval is late, a customer disputes a charge, a source record is corrected, or a required event never occurs.
You do not need to design the entire process around every rare exception. You do need to know which exceptions can cause material harm, who has authority to resolve them, and how the system should record what happened.
Training cannot repair a misunderstanding
Training matters, but it should teach people how to perform approved work in the new environment. It should not be used to compensate for unclear ownership, unreliable data, or a process the organization never agreed upon.
If users resist a new system, investigate why. They may need practice. They may also be protecting a necessary step the design overlooked.
Turn what you learn into requirements
Tracing the work gives the organization evidence. The next step is to decide what the improved process must accomplish: what information must be dependable, which decisions require authority, how handoffs should work, and which exceptions the design must support.
That does not mean making the current process permanent. It means understanding the work well enough to improve it without accidentally removing something the business still needs.
Once those requirements are approved, the organization can compare tools against the work instead of allowing a product demonstration to define the work for it.