Enterprise Microsoft Dynamics CRM implementations Gathering requirements
Introduction
Gathering requirements and setting the right expectations is one of the areas which can make or break a Customer Relationship Management (CRM) implementation. When working with COTS packages, asking a customer “What do you want?” without first showing what there is, is a ‘lose-lose’ scenario. This approach will likely result in unnecessary requirements which are not aligned with the package you are implementing.
Platform
One thing to start off with is to have a structured platform in place where you can store requirements. In smaller projects this can be as simple as an Excel spreadsheet, whereas in enterprise scenarios you would benefit from using an enterprise tool like Caliber or Microsoft Team Foundation Server. In any case, it is critical that the functional requirements can be viewed by multiple people at the same time and that they are under source control. This way you can go back and see when and why this requirement changed and avoid numerous discussions later on.
Seven-step process
Once your platform to store the functional requirements is in place, the actual requirement gathering can start. From my experiences I have created a seven-step process which will help guide you through this phase.
1. Identify one or more client stakeholders (I strongly advise having less than 3 people) who have strong expertise around the business processes. These are people who can make decisions and are willing to defend them on behalf of their line of business.
2. Introduce these people to the look and feel of your CRM product of choice using a general product demo. Show them how to navigate, how to perform Create, Read, Update and Delete (CRUD) operations, etc. .
3. Use a questionnaire to have a high-level conversation around requirements. In most enterprise projects, you will already have gone through a number of discovery workshops in the pre-sales phase where a lot of valuable information should be captured already.
4. Discuss these requirements with your CRM tool subject matter experts (SMEs) and let them come up with feedback and a high-level solution design for each of these requirements. For example, if a customer is looking for functionality X, but the COTS tool works in a different (Y) way, your SME should advise that functionality Y provides similar functionality and will keep the risk and costs lower.
5. Based on the SME’s recommendations and high-level solution design, have your development team create a number of proofs of concepts (PoCs). Make sure that at this point the developer standards and best-practices within the development team are already finalized, Otherwise you’ll end up refactoring a lot when the actual development phase starts. From my experiences, 80% of your proof of concept should be re-useable when starting the actual development phase.
6. Demo these PoCs to the customer and then have the conversations around the detailed business processes. When the business stakeholders can actually see what the tool can do, it will be a lot easier for them to come up with requirements that align with the “out of the box” solution.
7. Input all of these requirements into your platform of choice. The next step is then to start prioritizing the requirements on importance and business value. The final goal should be to have a clear phased approach in place with big chunks of functionality to define the scope of the several phases.
The final action is then to get a sign-off from your customer on this scope and then all of this information can be given back to the SMEs and development team so they can create a technical design document for your first phase scope. It is wise to hold off on the detailed phase 2 scope until you get to a state where the phase 1 development is almost finished, as this is something which can change based on questions and feedback on the development of phase 1.
Tips
When you get closer to the deadline of your phase 1 go-live, pressure will rise and certain gaps will be identified which might result in last-minute change requests for your phase 1. My advice here is that this can become a never-ending cycle and the only way to get out of this is to freeze your phase 1 scope and place further change requests in a future phase.
A final point to stress is that it is also very important to keep updating your functional and technical design documents during the implementation. Otherwise you’ll end up in a situation where your documentation is out of sync with what is actually developed and the testers will start raising false defects, and confusion will arise on what was agreed.
Conclusion
Gathering requirements is a very important milestone in every CRM implementation which should not be underestimated. The key objectives should be to set realistic expectations, define a clear scope, and keep aiming for win-win scenarios where you use as much out-of-the-box functionality as possible. As an enterprise service provider, Hewlett-Packard has a global pool of expert resources that can help guide you through this process. If you would like to find out more about this, please get in touch by sending an email to hpmicrosoftdynamicscrm@hp.com.
Thanks for reading!
