Are you a "documentation slave" for business requirements?
Documenting business requirements is one of those pieces of work that sends a cold shiver down my spine, particularly when preceded 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. That fact of the matter is that the more often you can show the business what the end result will look like, the more feedback you'll get and the closer you'll get to what they really need. Waterfall development kills all of that stone dead - high customer touch up front and 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, demonstrated 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.
What do you think? Have you seen too much focus on documentation and not enough on "doing" and getting feedback?
First published on Process Ninja. Reprinted with permission.