Microsoft Dynamics CRM v4 (xRM in disguise)

Having had detailed involvement with Microsoft’s CRM offering since the earlier adopter programme with version 1.0 then 1.2 (which nearly killed me and a number of my colleagues), then with great relief v3 (which gave many the will to keep going) and now v4 which is (IMHO) the best xRM-able product in the mid market space, I have watched with great interest and career investment the gradual repositioning of the product from a contact manager to a sales, service and marketing process enabler, to what is now a platform that is capable of being used as an application environment.  Still some way to go but the C in Dynamics CRM is slowly fading – in the marketing message and the logo!

My tip:  Version 5 to be named Dynamics xRM…

Applying the capability maturity model to xRM.

Slightly old school meets new world however I have had some success in using this tool with a couple of clients to clarify and order a massive agenda of work into a manageable sequence.  Sort of like arranging a menu for a dinner party ( I am a huge fan of seemingly unrelated examples and metaphors)…. 

1. Pump a few drinks and tasty snacks into the guests early to relax them, nothing too complex or else you will ruin their palette, but set them up for the entree. 
2. Entree creates the momentum for the main course where you complement the meal with a challenging bottle of wine to set off the dish.
3. Give them a few minutes to appreciate the main event and begin to digest things, then switch up with desert of a completely different taste – often one that wouldn’t have worked independently of the earlier courses. 
4. Finally a strong coffee / liqueur / whisky to bookend the dining experience and formally end the festivities. 

In a nutshell the perfect approach to satiating your dinner guests / clients!  Finding out what guests can stomach is a good idea when planning the menu – challenging them is fine (like giving a west australian shiraz to a frenchman),  poisoning them through allergies or offending their ethical/religious views is not! 

How do I assess the maturity of my client’s pallettes?  In several instances by using the capability matury model.

In future of posts I will run through a couple of methods I have found that can greatly assist in providing some context and definition to xRM practices (both new and existing) within an organisation. The first of which is the concept of a capability maturity model.

Note: The Software Engineering Institute (SEI) at Carnegie Mellon University in Pittsburgh initially developed the Capability Maturity Model which I have modified and simplified here. It has been applied extensively for avionics software and for government projects since it was created in the mid-1980s and in my opinion is one of the few frameworks that has become even more relevant in the post internet age!

The xRM Capability Maturity Model (xRM-CMM) is a good way to develop and refine an organisation’s xRM implementation process. A maturity model is a structured collection of elements that describe characteristics of effective processes for utilising and managing the business’s xRM capability.

The xRM maturity model has the benefit of providing organisations with:

• A place to start and organise xRM activities (ingredients)
• The benefit of using their own and the community’s prior experiences (pallete type and known allergies)
• A common language and a shared vision of the required ‘trajectory’ (wording the menu and time between courses)
• A framework for prioritising actions (picking items from the menu)
• A way to define what improvement means (next time you cook the dish)
• A method for benchmarking and performing equivalent comparisons (was this dinner party better than the last one?)

The xRM-CMM I prefer uses a ranking system of five levels, each with a progressively greater capability of producing quality xRM processes. The purpose of the xRM-CMM is to provide guidance for improving an organisation’s processes and it’s ability to manage the development and maintenance of xRM. The xRM-CMM provides a structure that I have found can greatly assist organisations to appraise its maturity with respect to its xRM capability, establish priorities for improvement, and implement these improvements.

The concept of an organisations ‘trajectory’ within the xRM-CMM is of fundamental importance as this recognises the implications from a funding and resourcing perspective as the organisation moves through the various levels.

(The perfect bottle of wine to complement the meal may be a Henschke Hill of Grace however if your budget won’t stretch that far then its no point considering it…)

xRM is a capability.

Capability: ‘A capacity, ability or talent that has significant potential for development or use’

The basis of many of my recommendations to clients in establishing an xRM Strategy is firmly themed upon the positioning of XRM within an organisation as a capability and not a project or software application. I believe that this fundamental change in mindset is necessary to fully exploit the benefits that xRM can bring to an organisation and to establish a suitable framework for its support.

In treating xRM as a capability it is strategically positioned in a way that removes the common project and application level boundaries and limitations. Two common mistakes in the management of xRM within an organisation are to classify and therefore resource and fund xRM as a project or as a software application.

If defined as a project, xRM will always be restricted in its scope, resourcing and allocated funding. All of which will result in customer relationship management being delivered in an ad-hoc fashion and laid on top of an organisations operations rather than embedded into them. Treating xRM as a project will also limit the efficiencies that can be gained in the development of common or reusable components as each piece of work will be bounded by its required functionality and will not consider its application elsewhere. Resourcing levels are another item that is limited within a project framework as they are generally limited to the achievement of the projects scope and not the exploitation of the capability from an enterprise level.

The mindset of project work by definition does not cater for ‘business as usual’ operations, which should be the end goal of any xRM strategy and as such will never assist an organisation in making xRM a core competency of it’s business.

Similarly, the categorisation of xRM as a software implementation is another common mistake. This approach sends the wrong message to the business areas of the organisation and reinforces a technical supplier style relationship rather than one of collaborative working. As can be seen within the xRM maturity model (which I will cover in a later post) those steps that are technical in nature are only a portion of the overall lifecycle and shouldn’t be given additional emphasis. This approach also usually sees funding become an IT function, which can adversely impact the business case justification process.

Capabilities, on the other hand, span both the business and technical areas of an organisation and bring with it ‘enterprise-level’ support and commitment. This approach ensures that the strategic framework under which xRM operates can combine the delivery of targeted implementations and the integration of xRM practices into an organisation’s core business. By not limiting the scope of xRM it ensures that resourcing can be applied in the correct areas (and change over time as required), and that a suitable funding model is applied that supports xRM under both the initial implementation and ‘business as usual’.

xRM – from the ashes of CRM…

Having been around during the first aggressive attempt by vendors to position CRM within the business/technology roadmap without truly understanding it’s role and then the second more damaging round where companies suddenly developed a massive appetite for this thing called CRM – they knew they wanted one but couldn’t define what ‘one’ was or why they needed it, however miraculously still managed to justify and coerce significant dollars, pounds, yen etc from their CFO’s and even appoint implementation partners to help with the realisation of their unquantifiable ‘dream’. 

Not surprisingly the majority of projects failed, the vision got tarnished and the vendors/ISV’s went away with slightly burnt fingers and cupboards full of marketing collateral to rethink their propositions.

A few successes were achieved however and more often than not it was due to these CRM projects having less to do with the ‘C’ and more to do with the business process and other items that surrounded the customer.

Vendors picked up on this principle and have begun touting a different approach to implementing their software and many clients have rethought their vision and focussed their attention on the top and tailing of their customers with the business processes and areas that are core to their position of customer centricity.  

The result of this is a groundswell of momentum for the application of the core building blocks of CRM – managing the lifecycle of something, the relationship of that something with other things, and the activities that happen to each of these things along the way.

Slightly less emphasis in managing the C and more on the X’s that make a business unique and provide them with strategic competitive advantage (one of these x’s is still a c!). 

Hence xRM. 

A few vendors have attempted to tag this term as extensible relationship management, extendable relationship management etc etc and are probably madly trying to copyright it at the moment.  However in a non Simon Cowell kind of way my interpretation is that it is the X-factor that makes a business work, or differentiates it from the pack.

These posts are an attempt to wrap some logic around this approach and share the experiences I have had, am currently having and will no doubt encounter with my clients and projects in this evolving arena.  I sit on the fence between business and technology so may well nerd it up on a few things that are IMHO cool or particularly useful.

Knowing myself there will also no doubt be the more than occasional tangent, general rants (not always rational ones) and a completely unrelated topic or two…