Most project overruns are requirements problems that surfaced late. The build was fine; what it was building was never properly pinned down, so it changed three times.
Business analysis is the work of pinning it down before anyone commits a budget. Not a wishlist workshop — proper analysis of how the operation runs, what it needs, and what “working” would actually look like.
What it produces:
- Current state analysis — the process as it really runs, the systems involved, the data that moves, and where the cost and risk sit.
- Stakeholder requirements, gathered from the people doing the work as well as the people sponsoring it. Those two groups routinely want different things, and finding that out early is the point.
- Functional and non-functional requirements, including the ones people forget until go-live: reporting, permissions, integration, migration, volume, compliance.
- Data requirements — what’s captured, where it lives, what has to move, and what has to be retained.
- Acceptance criteria, so “done” is testable rather than a matter of opinion.
- Prioritisation — must-have versus nice-to-have, with a defensible line between them.
The deliverable is a document a vendor can quote accurately from and you can hold them to. It’s also frequently the point at which a project gets smaller, because analysis reveals that a third of the requirement is already covered by something you own.