Documenting business requirements is one of those pieces of work that sends a cold shiver down my spine, particularly when preceeded by the word “detailed”. Some of the worst work on the worst projects I’ve ever seen has been achieved primarily due to the laser focus on creating phone book sized documents of “detailed business requirements”. Our reliance on them is a slavery to an old religion of business that needs to end. Thankfully the end is nigh.
Agile software development is playing a big part in that due to the high business contact of the method. Fact of the matter is, the more often you can show the business what the end result will look like, the more feedback you’ll get and you’ll get closer to what they need. Waterfall development kills all of that stone dead – high customer touch up front then the project dissappears into IT land only to emerge as some transmogrified beast that no-one wanted.
The other factor that will lead to the demise of the dreaded business requirements is the continued development of BPMS‘. Most BPMS vendors strictly push an agile implementation pathway, with the focus on building the processes and screens. Having worked with both Pega and Appian in recent projects, this really is the best way to go and almost totally eliminates the need to write business requirements. In my experience, whole processes and screen layouts can be built in a couple of days, demoed to the business and an iterative, agile cycle follows. If it sounds simple, that’s because it is.
Process isn’t just about challenging the way the business operates, it’s also about challenging our own holy cows. It’s time to challenge the concept of business requirements.
Cheers,
TPN
P.S. Need help with your process improvement initiatives? Drop me a line to explore how I could help your organisation.
Courtesy to Craig Reid. This blog is also available on The Process Ninja.
Follow
