Writing requirements that engineering actually builds — and tracking them from intake all the way through to delivery.
I’ve managed a roadmap of 140+ initiatives across seven internal stakeholder groups — Sales, Operations, Marketing, Finance, Technology, Training, and Support. Every one of them started as a BRD.
What I’ve learned: most BRD failures aren’t writing failures. They’re process failures. No intake structure, no stakeholder sign-off, no delivery tracking. The document gets written and then disappears into email.
This pillar covers the full pipeline — from how requests come in, to how requirements get written, to how you measure whether the delivery team is actually performing against the intake they’ve committed to.
How to write requirements that actually get built — structure, stakeholder sections, acceptance criteria, and the specific language that keeps scope from creeping.
Managing the queue when seven teams all think their project is the priority. Structured intake, scoring frameworks, and the quarterly review cadence that keeps a 140+ item backlog moving.
How to measure whether your BA team is actually performing — time-to-pickup, BRD work time, dev-start-to-end, and carryover rate. The numbers that tell you if the pipeline is healthy.
When two support organisations merged, the combined team had no agreed internal service levels. Tickets sat in queues with no formal response commitment and no escalation path that both teams understood the same way. Priority 2 responses were taking 20+ days.
The OLA framework established formal internal agreements between the merged support tiers — defined response targets at each priority level, agreed escalation paths, and a measurement layer that made SLA adherence visible to both teams and to management. P2 response time dropped from 20+ days to a 2-day target within one quarter of implementation.