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.
- They were successful.
- They were unsuccessful.
- 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.