Requirements for your software implementation - Three things you must do

13.10.19 07:32 PM By Matt Koopmans

Implementing new business software is hard. Way harder than it should be - and usually we are the cause of the complexity. We tend to understand what we do in the business, but we do not fully understand why we do it, leading for overestimating the complexity of the process. There are three simple rules you must follow to contain the complexity.

Before we proceed, this is not written as exclusive to waterfall, iterative, or agile deliveries. Where "requirements" are written in this article, you could replace that for "features" as required.


Work backwards from the outcome you wish to achieve

Every time I hear the phrase "we need everything we have right now, and all the things that make it better - but we cannot go backwards - AT LEAST we need what we have NOW", I prepare for a long project, with many change requests, and not to forget budget and time overruns.

It is obvious that the organisation is not ready to start implementing a new solution - they do not yet know which elements of the old solution are valuable to keep, and which do not add that much value. "Gimme what I have now, but better" is not a specification to which can be delivered. It also does not allow for any trade-off. If your current solution is your starting point, you do not inspire innovation, more likely you try to force a square peg into a round hole.

Instead - ask what needs to be achieved. Instead of writing requirements like: "the system shall ....", write an outcome and how it should be achieved. For example: "we need a higher engagement on our mailing lists" is a good start for an outcome (better would be if it was quantified with a number, say 20%). "In order to measure our progress, we need to be able to measure delivery, open, click, and bounce rates". "In order to obtain these metrics, we need to be able to send email campaigns to recipients with trackers".

By working your way backwards from an outcome, you prevent "requirements" slipping in that have no bearing on any outcome, but are merely a reflection of current operations.


Understand what you can trade - always ask: "at what cost?"

When you have a clear picture of the outcome, you are able to offset the costs of achieving that outcome against the returns. Certain things are simply required, otherwise there is operational standstill, or a regulatory violation. The rest is a simple matter of economic benefit. This can be direct benefit, such as an increase in output, or decrease in costs. This can also be a benefit from which other benefits could derive - such as increased employee engagement. It does not happen often, but when an organisation makes clear that "All requirements are essential, they are MUST HAVES", then there is nothing to trade. The project is 100% guaranteed to fail in this situation. Either the customer does not understand the difference between elements that could cause business standstill, and elements that simply would make things better. By stating that everything is a MUST HAVE, we eliminate the question: "at what cost?". Classify your list according to MoSCoW (Must have, Should have, Could have, and Won't consider now).

  • Must have - business standstill, unacceptable competitive disadvantage, or violation of regulations if these requirements are not met
  • Should have - adding these to the solution results in tangible benefits that outweigh the costs (high value)
  • Could have - adding these to the solution results in minor but measurable improvement, against acceptable costs
  • Won't consider now - adding these requirements results into a "garbage can solution"*, or the cost benefit simply does not stack up.

*Garbage Can solution: All problems are fit into the solution (the garbage can), until it no longer fits. At that stage, a larger garbage can is used, and repeat.

Prioritise for value

Roughly 80% of the value of any solution is delivered by 20% of its features. It shocking when you look at this statistic that still 70% of business applications projects are considered a "failure", either due to budget blowout or failure to meet expectation. When you are aware of this fact, you obviously frontload for value where you can.

In the requirements, as classified according to MoSCoW, add a column for value (make it a consistent period - i.e. value over a year). Now you can stack-rank the requirements in descending order of value; first for the Must haves, then the Should haves, and finally the Could haves.

If you are in an agile deployment, mix the highest value items in the first few sprints (a healthy mix of roughly 65% of the effort on Must have, 25% Should have, and the remaining 10% on Could have). If you are in a Waterfall deployment, ensure the high value items are front loaded, together with the must haves, early on. If you work for multiple releases, it would be good if each release could go into production - which allows for an agile like mix of Must have, Should have, and Could have requirements.

Finally during delivery, the agreement between customer and partner/vendor should be made (written) on what the exit criteria are - and at what stages these could be invoked. It is not necessarily a bad thing to exit a project prior to all the value being delivered. If you have 80% of the value from 20% of the features, and that 80% is already an improvement, then it can already be deemed a success. The remaining budget is almost discretionary spend. To make it worthwhile for all partners, an exit clause could be written that benefits both parties, should both parties have succeeded in delivering high value early on in the project.

To bring it home - Three actions

  1. Work backwards from the outcome. Don't give the current (or previous) system be your constraint on bringing that outcome at a reasonable cost.
  2. Be very rigorous in assigning the Must have, Should have, and Could have classification. Overestimating the requirement in terms of value is setting you up to not achieve 80% of the value in 20% of the features.
  3. Frontload value in your project, and have an agreement that is beneficial to both customer and partner/vendor to exit the project early if a value threshold has been delivered.

Matt Koopmans