Requirements Definition

It may sound obvious, but defining the requirements that an automated RM or Pricing application needs to meet is an absolutely crucial phase in any automation project, even if the application being implemented is an off-the-shelf piece of software. Making mistakes in the requirements stage is very expensive, as it generally results in a lot of re-work in all 'down-stream' activities. And making mistakes is very easy! A few pitfalls to beware of are: 

  1. Requirements gathering is owned by IT, who do not fully understand the business context; the system becomes technically robust, but business users are reluctant to accept it
  2. Or requirements gathering is owned by the business, and IT are saddled with an impossible job, without clear guidance regarding trade-offs between perfection and feasibility
  3. An off-the-shelf system is purchased; the user interfaces are very impressive, and nobody has the skills or inclination to question whether the logic it applies in its decision-making is appropriate in this specific business context, or whether it represents a change to pre-automation decision-making.
  4. Configuration options are badly understood, so 'plain vanilla' is again the flavour of the month.

In defining the requirements, one has to be both visionary and pragmatic at the same time; Vision is required to ensure that the core requirements are not compromised by practical constraints, and that the combined set of requirements result in a intrinsically coherent 'system'. Pragmatism is required to find an optimal balance between the benefits and cost, time and risk associated with each of the requirements, and to resist the urge to strive for perfection at all cost.

Even (or perhaps: especially) if the implementation project is mostly an in-house activity, it can be really worthwhile to get an external party to guide you through the requirements gathering phase. Pieter Dorhout Consulting has the skills and experience needed to avoid the many possible pitfalls, and to co-ordinate the activities in this early, and often somewhat fluid (or perhaps: dis-organised) stage of the project. Some questions that Pieter Dorhout Consulting can help you answer in this area are:

  1. Which decision variable(s), and therefore which business processes do we want to automate?
  2. Which other processes are affected by this?
  3. Who will use the system, and for which purpose?
  4. How will (or should) the logic behind the decision-making change?
  5. What are the expectations in terms of user experience and workflow?
  6. What are the non-functional requirements, e.g. regarding run-time and system availability?

Hiring PDC in the requirements gathering stage will cost a fraction of the cost of having to find out the answers to these questions the hard way!