A lot of my time day-to-day is spent talking about product features and benefits and how these can help businesses achieve their goals with our product(s). Increasingly however, I spend more of my time talking about CRM implementation best practise than I do about product capability. This pleases me. There are obvious reasons for this, the market is maturing, clients are becoming more knowledgeable and Microsoft Dynamics CRM’s major investments in recent times means I spend less time talking about its capabilities because my clients understand earlier in the process that it meets there needs. People understand that their decision and opportunity for success is less reliant on the technology but about how it’s used and if it’s adopted by the users. A typical conversation goes like this : Microsoft vision for the future, trends that we see in the industry and how that relates to our product(s), case studies and references  in the industry, product capability and implementation best practise. Now the best practise conversation is happening earlier.

Most of my time is spent talking about how Microsoft Dynamics product capabilities support and encourage implementation best practises.

A CRM project is a bit like cooking a meal, you need good ingredients and you need to cook them properly if you want your guests to enjoy the meal.

I’ve had the pleasure (and sleepless nights) of responsibility of over 100 CRM projects and I have made plenty of mistakes as well as picking some valuable lessons in that time. Some of these are shared below. You will also find links to some more in-depth articles I have written on the subject.

Start on the right track with a living project scope

Understanding and document the project fundamentals. This ensures that you understand the business objectives and project success criteria. As I have said may times before, project success is often based upon whether an implementation was delivered on time, a project should only been seen as a success if it meets the objectives of the business and the needs of the users. Don’t assume that everyone will read this documentation however, it is actually the process that is more important. Don’t get lost in documentation, and don’t use it as weapon to prevent change. Expect change and cater for it.

A scoping document can consist of the following:

• Project Background
• Project Assumptions
• Project Commercials / Business Case
• Project Methodology & Control
• Project Team & Contacts
• Project Scope / Out of Scope
• Project Requirements
  • Functional
  • Non Functional
• Go Live Plan

You can read more on this subject in my article: A Sample CRM Project Scoping / Initiation Document.

Continue on the right track with a sound process and project methodology

Describe and agree a Project Methodology and Control from the outset, describe exactly what this means and what the level of “project ceremony” will be. A good methodology with the appropriate project and control should:

• Allow the project team to work at maximum efficiency with the business requirement top of mind
• Allow the business users full transparency into the project with ownership and accountability of  the deliverable (under project guidance)
• Ensure a consistent level of delivery, work and service across the team
• Provide the ability to learn from previous projects, implement best practice and build upon that learning
• Ensure information is shared and that there are not unreasonable expectations placed on individuals
• Deliver frequent iterative deliverables with engagement of business users throughout the project
• Allow the project to quickly adapt to change

Implement a sound project prioritisation framework. Prioritisation is a key skill and one you should try to master. Make prioritisation activities a daily activity, always evaluating the most important items and moving them to the top of the list. Understand “Minimal Viable product“. Maintain absolute focus on features that are easily perceived as useful and benefits that are highly visible. Address the most challenging aspects of the project first, prioritise features and items that are architecturally significant as well as those that most clearly meet business objectives.

If possible and if the organisational culture allows, adopt an agile iterative methodology.

Beware of a project that is called an Agile project but in reality is still waterfall in nature. An Agile project is much more than just iterative development  so take time to truly understand and undertake the agile methodology, the Agile Manifesto is a good place to start. You will need the understanding and support of the organisation if you are going to successfully implement an agile methodology, you can’t do it on your own.

• The requirements process should deliver assets and visibility of requirements that:
  • Clearly outline to the client what they want
  • Clearly outline to the client what they need (the difference between want and need can be vast)
  • Clearly outline the priority of these requirements
  • Clearly outline to the developer what needs to be built
• Primary Requirement Documentation Artefacts:
  • User Stories
  • Use Cases
  • Workflow & Business Process Diagrams
  • Data Models
  • User Interface Wireframes & Prototypes

Prepare appropriately for the  workshops and the requirement gathering activities. Make sure you understand their competitors and their customers. Understand the industry, what is the history and how have business, technology, regulatory changes affected this. Tailor and Personalise the questions so that the workshop is relevant, it’s not their job to educate you on their business and it is likely that the business is making a significant investment by making people available for the workshop. During the requirements sessions keep asking why this will help you understand the root cause and the problem behind the problem. Often users will describe the solution to a problem instead of the problem itself.

You can read more on this subject with my articles on CRM Workshop Questions and Requirements Gathering Techniques and Product, Project and Day to Day Prioritisation.

It all about the business and all about the users

CRM User adoption is the key to CRM projects. Correlate and show a link between positive individual performance results and CRM usage. Measure User Adoption and tell users why you are doing the project and keep them involved throughout. Rethink how you evaluate and measure project success. Sadly, project success is to often measured by budget and delivery time-scales when really the true value is user adoption and return on investment of tangible business benefits. A project should only been seen as a success if it meets the objectives of the business and the needs of the users. So Iinvolve the business stakeholders and the users from the outset of the project, it is important to ensure that both the business and IT are  working towards the same goal. End user involvement and User Acceptance Testing should be done throughout the implementation life cycle and not just at the end. If you do it at the end you’ll discover problems to late.

A CRM project is not about technology it is about people and it is about the ability for the business to deliver value to their customers. It is not something that can be measured on a Gantt chart.

The value of a CRM project is broad user adoption across the organisation where information and data is being shared. Implementing CRM from a department to department perspective does little to consider the customer journey.

When assembling your CRM team make sure that you have representatives from users from all the various parts of the business. Identify your project champions , get them in early. All of my successful projects have had easy to identify champions, these people are bright, motived, extremely positive, understand the business and create an infectious environment . They can come from sources that are not immediately obvious so work hard to find them. More often than not these people are not senior but have been in the business for some time and are hungry for change and a CRM project is just the opportunity they have been waiting for to empower them to create this change.

Avoid seeds of discontent immediately. To achieve this you need to listen, you need a project structure and culture than listens to the users. Champions are great help in this regard. Stop discontent in its tracks, waiting until an issue becomes shared amongst a larger group will just be more difficult and costly to resolve later. Be wary of dismissing issues because they are small (from your perspective), be careful and evaluate your issues with care.

To return to the cooking analogy earlier, if you want your guests to enjoy the meal you need to know what ingredients they like and how they want it cooked. Having the food on the table on time is less important than serving a delicious meal you know they will love. Am I taking this analogy to far if I say Agile is a bit like Tapas? Ok time to stop.

You can read more on this subject with my article on CRM & User Adoption.

Thanks for reading.

Mark

This post was originally published on https://markmargolis.wordpress.com. This posting is provided “AS IS” with no warranties, and confers no rights.