Requirements Workshops: Operations, Finance and IT in One Room

Most system requirements are gathered one department at a time. Operations describes its needs to the project lead on Sunday, finance on Tuesday, IT on Wednesday, and nobody notices that the three accounts describe different businesses. The contradictions surface months later, in user testing, when they are expensive to fix.

Why separate interviews produce conflicting requirements

Each department sees the same process from its own end. The warehouse thinks of an order as something to pick and ship. Finance thinks of it as revenue, a credit check and a receivable. IT thinks of it as a record that has to pass between two systems without breaking.

None of these views is wrong, but each one is incomplete. When you interview teams separately, you collect three partial pictures and then ask someone, usually a consultant or a vendor, to stitch them together. That person has to guess where the joins are, and guesses become requirements.

Consider a building materials distributor in Amman replacing its accounting package and stock spreadsheets. In separate meetings, sales asks for the ability to release orders for trusted customers even when they are over their credit limit. Finance asks for a hard credit block with no exceptions. Both requests go into the requirements document. The vendor builds the hard block, because it was written more precisely, and the sales team discovers this on the first day of testing.

A shared workshop would have surfaced the conflict in ten minutes, and the room would have settled on the real rule: a block that a named finance manager can override, with the reason recorded.

Who should be in the room

The right group is small enough to work and broad enough to cover the whole process. For a single process area, aim for six to ten people. Larger groups turn into presentations.

• People who do the work daily. A senior storekeeper or accounts payable clerk knows the exceptions that managers forget. They are the most valuable people in the room and often the quietest.
• A manager with authority to decide. Someone has to say “this is how we will do it” when two teams disagree. Without that person, conflicts get written down as open questions and stay open.
• Finance, even for “operational” topics. Almost every operational step has an accounting consequence: a stock movement, a cost, a liability. Finance needs to see where those consequences start.
• IT or whoever owns the current systems. They know which data exists today, where it lives and what other systems depend on it.
• A neutral facilitator. This should not be the person whose department benefits most from the outcome. An internal project manager can do it if they are trusted by all sides; otherwise bring in someone from outside.

A workshop agenda that produces usable output

A half-day per process area is usually enough. Longer sessions lose energy, and shorter ones never get past the easy cases. The sequence below works for most process areas.

1. Agree the scope in one sentence. For example: “From the moment a customer order is received until the invoice is posted.” Write it where everyone can see it, and point to it whenever discussion drifts.
2. Walk one real transaction end to end. Pick a recent order, purchase or claim and trace exactly what happened to it, using the actual documents. This is far more reliable than asking people to describe the process in general.
3. List the exceptions. Ask “what goes wrong?” and “what is different for some customers or products?” Partial deliveries, returns, price changes after order and urgent orders usually generate more requirements than the normal flow.
4. Mark decisions and handoffs. At each point where something moves between teams or someone approves something, note who decides, what information they need and what happens if they are absent.
5. Capture data needs. For each step, ask what information must exist and who creates it. This is where finance and IT usually find the gaps.
6. Read back and confirm. In the last half hour, read the captured requirements aloud. Anything the room cannot agree on goes on a short decision list with a named owner and a date.

Handling disagreement without losing the room

Expect disagreement. Bringing it into the open early, with the people who can settle it in the room, is the reason for holding the workshop. Most conflicts fall into a few patterns, and each has a sensible way through.

When a conflict cannot be settled in the room, do not let it consume the session. Park it on the decision list, name the person who will decide, and move on. A workshop that ends with three clear open decisions is far more useful than one that ends with an hour of unresolved argument.

Turning the session into requirements vendors can use

The raw output of a workshop is messy: sticky notes, photos of whiteboards, a facilitator’s notebook. Within two working days, turn it into a short written record that participants can check. Leave it longer and memories start to rewrite what was agreed.

Good requirements written from a workshop have a recognisable shape. Each one names who does something, what the system must allow or prevent, and the condition that applies. “The system must block order release when the customer’s overdue balance exceeds their credit limit, unless a user with the finance manager role overrides it and enters a reason” is testable. “The system should support credit control” is not.

Group requirements by process step rather than by department. This keeps the cross-functional view that the workshop created. It also makes it easier for a vendor to show you, step by step, how their product handles each one during a demo.

Finally, send the document back to the participants and ask them to sign off on their area. Sign-off has a practical purpose here: it is how you find out, before you sign a contract, that the storekeeper meant something different from what was written.

Better systems start with a shared picture

A requirements workshop costs a few half-days of senior time. Skipping it costs change requests, delayed go-lives and systems that each department works around in its own way. Getting operations, finance and IT to describe the same process together is one of the cheapest ways to reduce risk in any system project.

This is the starting point of our Enterprise Systems work: requirements analysis built on how the business actually operates, so that design, data migration and integration are based on agreed facts. It reflects the Know and Map stages of the KEMLAT Method, where we understand reality first and turn it into a clear operating picture before anyone chooses a tool.