BA on IT Project
Most IT projects do not fail because of bad code. They fail because what was built does not match what was needed - and no one caught the gap until it was too late. This engagement is about being the person who prevents that.
What this engagement covers
When a business commissions a software development or system implementation project, someone needs to sit between the business and the development team for the entire duration - not just at the beginning. That is this role.
On one side: understanding exactly what the business needs, capturing it completely, and making sure nothing is assumed or left unstated. On the other side: translating those needs into language that developers can work from, reviewing what they build against what was agreed, and flagging divergence before it becomes expensive to fix.
This is not a project management role. It is a content role - about the substance of what is being built, not the scheduling of who builds it. The business analyst on a project is the person who knows both what the system is supposed to do and what it actually does at any given point, and can identify the difference.
The engagement also includes budget oversight: tracking what has been spent, what remains, and whether scope changes are being properly costed and approved. IT projects are well known for budget overruns that could have been caught earlier. Catching them earlier is part of the job.
The deliverable is not a document. It is a working system that does what the client expected it to do, on a budget that was understood and controlled throughout.
How it works
Warehouse management system - process adaptation for a multi-zone facility
A logistics company operating a distribution centre needed to adapt their existing warehouse management system to the specific layout and operational requirements of a new facility. The new warehouse included a three-level mezzanine picking zone - a configuration not supported by the standard system - and required changes to three core processes: vehicle unloading, goods receipt, and stock placement. The project ran from functional requirements through technical specification, development, testing and user training. Budget figures below are illustrative; actual project financials are confidential.
Six functional changes across three warehouse processes, delivered over 12 weeks. Each change was scoped, documented, developed and tested independently, with a single BA maintaining continuity across all of them.
Illustrative budget structure showing phase weights for a project of this type. All figures are representative only - actual costs vary by team composition, development rates and scope. Real project financials are confidential.
Extract from the FR document covering Change 1.1 - Trusted Unloading Mode. Each change was documented to the same level of detail: background, numbered requirements with priority and conditions, and explicit acceptance criteria used for testing.
Extract from the TS covering the processing algorithm for the first barcode scan in trusted unloading mode. BA role included reviewing all such diagrams against the FR to ensure completeness and correctness before development began.
Extract from the operator instruction for the trusted unloading mode, produced as part of the handover package. Instructions were written to be used independently by dock operators from day one, without requiring developer support.