The business needs a new CRM or ERP Application, there’s no doubt about it. The budget and requirements are understood, resources are available, and all parties are ready. More often than not the next step tends to be one of the following.
1. Scour the marketplace for applications that look likely to meet the “requirements”, compile these applications in some spreadsheet and begin a process of emails, contact us forms and phone calls to arrange demonstrations
2. Create an RFP or RFI with some high level requirements and distribute these to vendors. Compile responses in some spreadsheet and begin a process of emails, contact us forms and phone calls to arrange demonstrations
Both approaches significantly overlap in actions. The question here is, are either approaches the best in selecting an application?
Perhaps, but what is baffling is the fact that requirements gathering, the stage at which the business decides what it requires is nearly always carried out AFTER system selection!!! Odd…right? Maybe there is some subconscious primal instinct at play here. Or the brain stem “the lizard brain” referring to the oldest part of the human brain is in control.
This is the difference between “Show me what you have and I’ll pick from that” and “this is what I want, now show me if you have it”.
It is possible the selection is more accurate and successful if detailed requirements are carried out first. This may prolong the process, and that would be correct.
It would prolong the selection process but it wouldn’t prolong the complete selection and implementation project combined. Since it’s necessary to carry out requirements gathering at some stage of the project.
The key aspect here, is the scenario when the business is firm in its conviction to make a selection.
After requirements gathering it may be useful to then go to market initially for reconnaissance and use the information to enhance and modify the existing requirements.
Only after this would going to market via ways of RFP or RFI be truly fruitful, as it would be easy to provide vendors all the information required required to respond accurately and prepare more relevant demonstrations.
A possible theory for the current situation of Requirements After Selection is that users within the business do not really know what they want and or when they do have great difficulty verbalising this, so the tendency is to push back the process as far back into the overall process as possible.
In addition performing the requirements after selection allows the business user to rely on the selected system to direct or remind the user of requirements, in addition at the requirements gathering stage there’s nearly always an implementation consultant onboard that will be relied upon to serve as a business analyst and help shape the requirements.
Yet, there’s an opportunity for a paradigm shift here. If you have experiences where detailed requirements were carried out before selection, let us know.
For more customized news and articles, get in touch with us!