Stop doing business requirements

It’s probably time for me to stop doing ‘business requirements’; at least in the big up-front way the BCS, IIBA and BABOK seem to advocate in their training.

I’m certainly not going to categorically stake my reputation on this claim, as I don’t want to become known as the business analyst ‘who doesn’t do requirements’.

But I do think the days of spending 3 months and consulting 20+ stakeholder groups to get their input on a legacy system replacement are truly numbered and/or already dead. Unless you are the US military perhaps.

I’ve actually done this kind of role more than a few times in my career, I hate to admit, usually inside some kind of consultancy team brought in to rationalise systems.

It always feels pretty good the day you finalise that requirements spreadsheet containing 200 rows of stakeholder needs or upload a lengthy business requirements document (BRD) to SharePoint. Knowing the requirements gathering Zoom roadshow has ended.

What should happen next (according to the plan) is a build-vs-buy decision, firmly underpinned by the comprehensive business requirements, before swiftly moving into implementation. But the thing is, I have never actually seen it happen like this.

What actually happens is vendors don’t want to read the lengthy BRD and feel the RFP is too onerous to complete, but if they do spend the time, they hike their price to compensate for the pre-sales effort and the significant customisation that will eventually be required for their product. Procurement then negotiates a much lower price by agreeing to a firm delivery of the most important business requirements, still at a much elevated price.

Internal development teams don’t usually work from business requirements anyhow, so if you have one of those then someone will need to convert the business requirements into user stories or something similar. And that will require taking the highest priority stories to start with, making everything else just high-level roadmap items off into the distance.

Either way and in both cases, perhaps 3 quarters of the business requirements (and effort expended on gathering these) get pushed into ‘subsequent project stages’ ie kicked into the long grass, likely to not ever see the light of day.

What I suggest as a much better practical alternative is a 1 or 2-week intensive requirements “triage” across all available stakeholders, to quickly flush out the most urgent needs. And take those findings into commissioning a vendor product or direct implementation as quickly as possible, building out a tactical beachhead.

Spend the time saved on business requirements gathering to consider how to achieve a parallel running between tactical new, and legacy old. Embrace testing and learning as you go, reminding yourself that direct actionable user feedback is much more valuable than a comprehensive requirements catalogue, too big to implement anyway.

Ensure the legacy system remains fully “on” until the new system becomes a compelling enough replacement.

If you are unhappy with your development team, they may need more detailed guidance.

Better software requirements can help with this.