Home > Work > Why are business requirements always so rubbish?

Why are business requirements always so rubbish?

OK, perhaps not always, but surprisingly often. I have worked on a several failing projects, and almost always they failed right at the outset by making a mess of the requirements. Here are what I have found to be the most common reasons for poor requirements, in no particular order.

1. Lack of clarity in understanding own processes

The key business users unintentionally hinder the discovery of the full set of requirements, including

  • focussing on the part of business they understand best, based on their own current or past role, to the neglect of the rest.
  • failing to involve others in the team who do the job now, so that the requirements capture what used to be done rather than what is needed now.
  • have been doing the job for so long nothing is documented, and they struggle to recall all the edge cases out of context.

2. Incorrect specification

This is where, irrespective of the above, the requirements reflect some major flaw in the business’s approach, which is initially hidden from the development team.

  • The requirements describe the current process, but it is sub-optimal.
  • We’ve had a great idea but we haven’t tried it out in practice.
  • There will be change, but we don’t know what it is yet, so we’ll have a guess (but not tell you we’re guessing).

3. Inability to make a decision and stick to it

Sometimes it is right to change a previous decision, when new information comes to light, but too often decisions are repeatedly revisited and reversed, when nothing has changed. This seems to happen most often in large organisations where there are too many stakeholders and politics takes over.

4. Defining solutions, not requirements

This is not always a bad thing, as some system context is usually appropriate (e.g. target operating system). However one system I worked on was to implement a Direct Debit system to accept payments, when it soon became clear that the most cost-effective solution would be to employ an additional part-time cashier. The business would not countenance this and insisted that it had to be collected by Direct Debit at a much greater cost.

5. Inability to write clearly and unambiguously

We are all guilty of writing rambling sentences containing tortured syntax. Business jargon is often used without clear definitions. Both give plenty of scope for misinterpretation. Ordering the requirements within the specification in a coherent sequence can also be difficult, making it hard to spot all related requirements.

6. Focus on process, not quality

Some organisations focus on demonstrating that a process is being followed for its own sake, not for the benefits the process is supposed to bring. Success is judged by the presence of a ticked box on an audit form, not by the quality of output. Numbers are easy to measure, quality isn’t. I worked in one organisation where a full set of documents was always produced and formally agreed by all concerned but its content were neither accurate nor complete, and of no value at all. (But we passed our audit). There is no excuse for this.

7. Hurried requirements

A weak manager under pressure thinks: We’re already running late, so we’ll do a quick job and lob it to the developers, and then we can claim that the project is still on time, and leave them to sort it out later. Hopefully I’ll have moved on by then…

Advertisements
Categories: Work Tags: ,
  1. No comments yet.
  1. April 28, 2010 at 8:36 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: