Traditional methods of procurement generally involve some sort of “scoping” before a formal specification is drafted. Usually the service director wanting the software is asked to make a business case; from this, the product to be procured is defined. A list of requirements is created, and circulated to potential suppliers for comments, and eventually a draft Service Level Agreement and/or Specification is created so that procurement can begin.

Recently we received a 12 page document listing the requirements for a new event applications process. It was full of detailed descriptions of the various functions that the consultation group had thought up, all described as “essential”. It was a very thorough piece of work, outlining a software service that would complement the work of a city council’s busy events department perfectly. It looked remarkably similar to the original “wish list” we created when we first started to make our event application platform (EventApp), six years ago.

As I read the document, I was reminded of heated discussions between our development team and our user group, (refereed by me), as we worked out our stage 1 scope. The process of paring down the wish list was painful. Cherished functions were dropped and workarounds were devised, to make the project scope fit the budget. Also, the user group could not agree on how some of these functions should work; to build something for one faction would have alienated the rest. The only way forward was to drop the subject and agree to revisit it in stage 2.

As the project progressed, and we evaluated user feedback from version 1, we discovered that including these dropped functions might make the system unworkable. We would be adding considerable extra complexity, for very little added value. Real world experience meant we could work out which functions were useful and more importantly, which were not. As new versions were released, we included some new functions to improve the platform. We still did not include many of the ideas that seemed important in the original wish list.

I have a background in the film industry, and I am a fan of serious editing. All the best editors have a saying, “if in doubt, cut it out”. Producers and directors are often horrified by a good editor’s willingness to discard scenes that cost a fortune to shoot. Generally, cuts make the film leaner and better, but it’s so difficult to see this at the script writing stage. The film editor and the software developer are both striving to remove complexity, and the earlier this is recognised, the less resources are wasted.

To win this tender, and to comply with the 12 pages of requirements, we would have to include the functions that we have already discarded. However, we would never do so, because our software (and our existing clients) would suffer. During development we avoided many blind alleys and expensive rabbit holes, because we did not follow our predefined wish list.

So, a purchaser has a choice, they can commission bespoke software or they can save a lot of time and money by choosing an existing SaaS platform that’s stable and proven to work. If they choose the latter option, like Mick Jagger, they must accept that “you can’t always get what you want”. However, as the song continues, “But if you try sometime you find, You get what you need”.