CRM Business Analysis - Best Practices

In most of the project I was in , usually the client don’t have a clear view of the requirements, because either we are implementing a system for the first time or they have some requirements from the old system therefore we need to be cautious with the change management. 

Many of the organizations do quality work around project management and practiced some SDLC, be it Agile or Waterfall. However, the analytical expertise in the business analysis are the most important factor that serves as a differentiator for achieving success in the project.

In terms of required requirements we need to create prototypes (POC`s) in a storyboard fashion which will allow the client to see himself what is being delivered in the solution. But my advice here is never allow a POC to become a production solution, this will bring problems in the future. So the business stakeholders need to see this business process reflected on the solution, but they must be prepared for change.

What only matters is if the stakeholder is the owner of the process, otherwise we are spending our time and the requirements will be changed after if his not the one how is going to decided, so we need to meet with as many stakeholders as we can as many times as we need in order to gather our requirements.

A requirement must have only ONE requirement and on it several tasks, make sure it can be testable otherwise is consider invalid requirement. Bear in mind that we are talking about requirements and not features, features is what we deliver when we build a solution in CRM case we deliver requirements because we do services. Unless you are building vertical solution like FieldOne, ClickDimensions, Adxstudio or other type of vertical.

In many meetings I hear "system must be user-friendly?", this don’t tell us nothing, the use of mock-ups will help the user to understand how easy and user friendly is. Or “we should use the same front end like the old system, because people are used to it”, don’t try to invent the wheel, otherwise we are not given any value to the customer in actual sense for longer-term, in this case the question should be “why you want to change?”

Validating the requirements and getting the sign off is important, otherwise the customer will think we are incompetent for going back to for more clarification, and in mean will they will change their mind, this way you will avoid adding trash kind of components to your solution . For e.g. Fields or plugins which will never be used again.

It is essential and the best-practice process says to create documentation, but sometimes this is basically impossible when we are doing Agile approach so try to document the maximum at the beginning of the project, otherwise you will spend lots of time updating the documentation, with all the workflows, plugins, JavaScript`s, entities and relationship’s, use the tool on the XrmToolBox to help build generate this documentation for you, don’t think all will be done on the fly.

With each step forward you will improve your methodology and you will gain commensurate benefits in the speed and accuracy. 

In most of the process and workflows we should use BPMN because is VERY important to understand how process will work and how we build it in CRM. For examples, let’s consider server side components in a typical CRM implementation. Since the creation of the record on entities until all the plugins and workflows involved to build that process. Bear in mind all the integrations and web services should all ways been mention on this flows and diagrams. This will help the developer and we can always have the sign off of the process from the client.

There will be conflicts among people and how they see a requirement. Make sure you help facilitate agreement, help then to be identified with that requirement and own it and as I said before, make sure you are dealing with the owner of the process, and this will help you to mitigate failures and mistakes.