« 10% 20% 30% What's a "Good" Process Improvement? | Main | Ask The Ninja! What would YOU like to read about in my next whitepaper? »

November 18, 2013

Business Requirements - The End is Nigh

image from www.sxc.hu
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.



P.S. Need help with your process improvement initiatives? Drop me a line to explore how I could help your organisation.


TrackBack URL for this entry:

Listed below are links to weblogs that reference Business Requirements - The End is Nigh:


Feed You can follow this conversation by subscribing to the comment feed for this post.

Agree 100%.

I am Appian customer and we joke about our requirement documents being post it notes ... but they are!

People should undervalue at their peril the concept of process based development using BPMS such as Appian. Seeing is believing for stakeholders and being able to return to them within a few days something that enables them to relate to what their end goal or issue may be is fantastic.

I forgot to mention that within the "few days" it is more often than not working as well :)

Great article Craig.


I'm interested to hear how this would on a whole of government project where the changes you are wanting to implement affect external and internal clients and the project you are working on is a component of a larger project?

David - thanks for the comment - it's great to hear that others are having the same success using agile methods of delivery.

Brett - I don't see any barriers to it not working on the project you mention. I often find that people are reluctant to involve external clients as it is somehow perceived that they are "putting them out" - I'd suggest that whoever is involved in the process from a customer experience perspective needs to be involved throughout. In this example I'd suggest an agile approach is even more critical as you can have a higher level of touch with the multiple parties involved.

Hmmm, working on a Pega project now, using PRPC to record use cases with xref to data elements and business rules. Sounds like requirements to me.

The title definitely attracts lots of attention whenever talking about requirement documentation.

It tells lots of the story with just screen and process. They are like the skeleton of a project outlining the high level requirement. For business user, visualized communication tool is no question much better than a phone book sized technical requirement.

However, depending on the maturity level of the development team and relationship between business stakeholder and development team, detailed requirements can be very useful as a communication tool and based line for development team.Especially, in a environment, team is located in multiple locations. For example, the majority of development team are in overseas, business stakeholders are based multiple Australia major cities.

Hi Craig

You have stated an inhibiter to efffective process improvement is the view that it has to be resolved by the introduction of a software application i.e. the best outcome quite often is to tweak the process. Am I on the wrong path in taking Agile software development to mean that process improvement using it is software based processes, or is it software that helps develop manual coalface process for the end-user?

Hi Brett - no that's not what I said. I'm a huge fan of using technology to improve business processes, but I'm also a huge fan of not wasting time documenting things that don't need to be documented. Tweaking the process (no software) is great and is the first step I advocate before software automation, but if you're only tweaking a manual process, why bother documenting requirements - just do it! It's all about GSD - getting stuff done.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.


Post a comment

Comments are moderated, and will not appear until the author has approved them.