The Danger of Requirements Clustering

Over the years I’ve worked on a lot of software development projects which were tasked with building a “system” which attempts to meet all of a group of users immediate requirements. These projects always had one of three outcomes.

  1. They were successful.
  2. They were unsuccessful.
  3. They were unsuccessful but claimed to be successful.

The reason for the distribution across these categories are many and getting agreement into which category a project falls is largely subjective. If the bar is only that some utility out of the system was gained then a goodly percentage could be claimed to be successful (in the order of 75%).

In my opinion, “some utility” is a pretty low bar. In fact most projects end up producing “stuff” that doesn’t get used. One of the reasons for this is that we tend to cluster requirements together into a “system” which will attempt to meet all our current and future requirements but as agile teams would know (and argue) requirements are a moving target that change no sooner than you have defined them.

From an agile process point of view, the solution then is to resist the temptation to define too many detailed requirements up front (although some visibility is necessary to avoid “doing something stupid”) and focus on the shorter term objectives that will deliver business value. The next most important requirement will be obvious once you have delivered the preceding requirement.

One of the reasons we tend to cluster requirements into systems is because access to development resources from business users is limited and so once they get a time-slice they want to get as much into the buffer as possible.

To help mitigate this problem we need to design the internal IT organisation to be a little bit more like an operating system which shares the resources around based on relative business priorities and packages work up into small executable chunks and where the various business units are confident that they will get a time slice some time again.

2 thoughts on “The Danger of Requirements Clustering

  1. The OberGruppenFuhrer

    Humans aren’t actually very good at context switching/ time-slicing. This is why you so often find a developer not working on what they are supposed to be working on because they ‘just want to give it a final polish,’ or ‘it is more interesting’ etc, etc. Of course they’ll bill the time to your project, they just won’t be working on it.

    There’s also a fair overhead in starting a project, setting expectations, identifying stakeholders, and defining organisational costs and benefits.

    What you propose probably works quite well in a maintenance scenario.

  2. Damian

    I remember seeing the results of a study last year (that you can take with as many grains of salt as you like) on big software projects and the link between the requirement gathering methodology and the usage of the end features.

    The results were along the lines of, 85% failure rate in the projects. The ones that were deemed to be successful had only an average 10% feature usage for projects with a big formal requirements gathering phase. The more agile projects did a lot better, somewhere in the 60% range I believe.

    I went looking for the study this morning, but my google skills are failing me.

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