Why do requirements gathering?

Let us suppose that your organisation is contemplating implementing a new business application; perhaps a new finance system, CRM, document management system, intranet etc. The starting point for many such business projects is to identify the business problem you want to solve (or opportunity you want to exploit) and then to gather requirements from the business. But some organisations balk at the idea of consulting their staff about what they need. At 3Kites we believe strongly in asking the business about their requirements before proceeding to spend money on systems.

Where the range of potential solutions is small, the extent to which all the business requirements can be met may be limited, especially if the organisation starts from the principle of avoiding customisation wherever possible, which we would certainly endorse. But it still makes sense to ask the business what they need before you go ahead, purchase and implement a new system. The reasons for gathering requirements are wider than just to identify which solution to implement:

• Clearly, understanding the business’s requirements is part of the due diligence process before spending substantial amounts of the organisation’s money.

• It also helps to understand the key pain points and priorities before looking at potential solutions, so that you will make sure to look carefully at the relevant parts of the products’ functionality

• Importantly, requirements gathering can be the start of business engagement with the project. On the whole, people react better to change if they feel they (or at least a representative selection of their colleagues) have been involved in the process, rather than having change imposed upon them in the abstract. It avoids the 'how could you have been so stupid as not to have thought of…..?' reaction after rollout, and helps to build trust in the project. Of course, you need to manage expectations so that staff do not assume that every suggestion they make will be implemented.

• If part of the reason for the project is to improve efficiency, identifying the real pain points and addressing them is going to be important. When it comes to configuration decisions about the product – of which there will often be very many, at a deep level of detail, quite quickly once the implementation project begins – you want to have an idea of which way to go. You will also want to ensure that the project also delivers some of the ‘nice to have’ features that will make staff more willing to adopt the change you are proposing.

• As part of your change management efforts you will want to know in some detail what staff are doing now, in order to identify how their life is going to change. You will also want to identify people to use as a reference group during the implementation – the keen ones in the requirements gathering process will be good in this role. They may also be willing to act as testers and 'champions' for the system.

Perhaps worse than not gathering requirements is gathering them but then forgetting about them when it comes to implementation.

If you'd like to know more about how 3Kites can assist your firm, then please contact Danielle.Leacock@3Kites.com

Click here to read the full article as a pdf.