Functional & Business Analysis

Hire Business and Functional Analysts

Process, configuration and the specification behind it.

The specification decides most of the cost of a programme, and it is the part most often treated as paperwork. A requirement written as "the system should allow the user to approve" hides every question that matters: who, on what basis, what happens to the thing they did not approve, and what an auditor sees afterwards.

Analysts here are expected to produce something an engineer can build from and a tester can fail — the process as it is actually run rather than as it is documented, the exceptions people have been handling in a spreadsheet, and the data that has to be migrated and reconciled before any of it works on day one.

The gap between the documented process and the real one is where most of the cost hides. The documented version has no exceptions in it. The real one has a supervisor who overrides a price by phone, a spreadsheet tracking the twelve orders the system cannot represent, and a rule everybody knows that is written nowhere. A system built from the documented version goes live and immediately acquires a shadow spreadsheet, because the exceptions never went away.

Finding the real version takes a different method from a workshop. Following one live case end to end with the person who handles it, and asking at every step what they do when it does not go that way, produces things a workshop never will — partly because the exceptions are unglamorous and partly because the people who handle them are rarely the people invited.

An acceptance criterion is finished when a tester can make it fail, and that standard disqualifies most of what gets written. "The report should be accurate" cannot fail; it can only be argued about. The version that survives names the input, the expected outcome, and what must not happen — the document that must not post, the user who must not see the record, the second submission that must not create a second order.

Data is part of the same job, which is why migration sits in this group rather than with the engineers. Which records are coming, what happens to the ones that are not, what a control total will be compared against and who signs it are functional decisions. Taken in week two they are conversations. Taken in cutover week they are delays, and by then nobody has the time to take them properly.

Business Analysts

Analysts who write the exception path, not only the happy one, and produce something an engineer can build from.

Data Migration Specialists

Specialists for the part of a go-live that decides it — extraction, cleansing, load and the reconciliation that proves it worked.

Teams are built for companies in the United States and the Gulf — the UAE, Saudi Arabia, Qatar, Kuwait, Bahrain and Oman. The engineers are in Pune, which matters mostly for the clock. Dubai is ninety minutes behind us and Riyadh two and a half hours, so a Gulf team shares almost the whole working day. New York is nine and a half hours behind, so American engagements run on a written handover and one fixed overlap window rather than on a standing call — a real constraint, and better stated than discovered.

What to look for when hiring

Ask them to describe the exception path for a process they know well. Anyone can describe the happy path; the requirements actually live in the exceptions. A second test is to hand them a requirement they wrote and ask what a tester would do to fail it — if there is no answer, it is a statement of intent, and it will be reopened as a change request in the third week of testing.

Tell us which roles you need

Tell us which roles you need, and when.

Functional & Business Analysis, or a mix — tell us what the team would be working on and we will say what it takes to staff it.