When does organic growth becomes viral?

Some managed scope creep during a project is normal and in a green field site implementation to be expected as the requirements become a prototype and then a system, additional context is achieved and can sometimes lead to a necessary extension to scope.

In the early stages of a project – especially where users may never have had to think of what they do in terms of process steps, inputs/outputs etc etc and everything else we get them to consider during the requirements gathering phase – this is just part of the iterative nature of xRM projects, however there is a fine line between getting the business decision makers to consider things relevant to the purpose of the xRM implementation without opening it up to everything they have done, currently do or might possibly one day consider doing…

In this case it is the inherent universal relevance of xRM that has become the implementation teams worst enemy to a degree.  Now that the approach has been demonstrated to them and there is an understanding that ‘yes it can do that’ and ‘no it won’t take 6 months’ there is a liberal amount of enthusiasm surrounding the prioritisation process for change requests, new requests and what if requests coming through from the client.

We are increasingly finding ourselves drawing back to the original business case and objectives to be the sanity check for the should we and will we decision that these requests require.

So far the client is onboard with this and we are trying to capture the enthusiasm and flood of ideas coming up from the floor as part of the next round of the engagement however it is an interesting reminder again of too much of a good thing…

Role based Wiki’s

First it was blogs – then podcasts – now wikis…

The Microsoft Dynamics ISV evangelism team has recently launched a wiki for MS Dynamics CRM enabling implementors, ISV’s, customers, partners, lovers and haters of MSCRM to wiki their way to enlightenment.  Check it out here.

The issue with all content on the web is the sifting of what’s relevant for me in trying to do the thing i am attempting to do right now.  A wiki may be the answer, or it may be something that is ok to a point but then can’t scale.  I will be watching this as well as the slightly older SalesLogix one with interest to see if there is any relevance at a local level.

We are currently rolling out a vertical solution where the concept of an internal forum amongst the user community (which is across agencies but in the same industry) where resources, help, tips and queries can be managed. 

As i have mentioned earlier we are using collab tools for the project team however are needing something that is anonymous-ish and readily available to the broader non project team user community. Perhaps a wiki will do..

Letting the punters loose.

Currently approaching a key go-live date with the users now eagerly hammering away on a UAT environment.  Taking a slightly different approach to a normal UAT phase as its a green field site where we are replacing a manual process with an xRM implementation (Contract and Customer Management). 

The risk was that the introduction of automation in areas that have always been manual would see the users lose context in their tasks as many positions and job roles were focussed on the process rather than the outcomes.  Collating information for KPI reporting purposes etc which are now all generated from the application was a key component of several positions for at least a few days each month.

To mitigate the risk of bewilderment our approach was to observe and notate 3 random over the previous month (start of the month, mid month and during end of month reporting) which resulted in the creation of running sheets for several ‘days in the life’ of the various user types.  This document then strongly influenced the UAT sheets and user guides and identified areas that were potential ‘bewilderers’ for users as the xRM application would take them from operational data capture and record management to KPI reports without the collation and QA process etc.

To shave down the levels of potential bewilderment in the short term we created an extended report that allowed the users to verify the process and data being collated for the end of month figures.  Even though this report doesn’t change the KPI generation report in any way it provides users with a mid month method of gaining back a sense of accumulative context.  The vision is that after 3 or 4 months of using the report the gap between the inputs and outputs of the application won’t be a source of bewilderment for the users and they will be comfortable to do away with the task of checking the report and move onto other tasks.

Early signs are that this step has reduced the risk of this giving users a negative experience with the application.  Looks like it will be a politically smart move and one that only cost an extra half days dev effort.

Music: Fleet Foxes

Stumbled across some Fleet Foxes tracks yesterday – wow. These guys have a mighty fine vibe about them.  Glad to see Seattle is still capable of producing gems.

Have a listen to Fleet Foxes here.

Determining xRM project requirements.

Pre-sales activities have been a bit all consuming over the past few weeks however it is refreshing to see clients on the same page (both as us and with each other!).  A simple method i have been road testing in the process of discovering client requirements has been to break any talk of functionality down to the grass roots.

1. What are the things involved – people, processes, products, services, content, etc etc
2. What is the lifecycle of each ‘thing’
3. What is the relationship between each ‘thing’
4. What is the lifecycle of that relationship.

Leads to lots of diagrams (might get around to publishing a couple here later to illustrate the point) however has been very useful in generating the macro level understanding of what’s in scope and which parts of the business are the most complex.

From MOSS to Basecamp.

Doing quite a bit of work across state lines at the moment and have recently scaled down from the use of SharePoint sites for each project – managing client logins etc etc which turned out to be great but a bit of overkill – having endless opportunities and bits of functionality actuall distracted the project team from the core (and billable) work to be done. So we have moved to a SAAS collaboration app Basecamp.  Another offering from those clever chaps at 37signals.  Whilst being pretty basic and clunky in spots it does 90% of what is actually required from a project collaboration tool and is easy enough for clients to use without instruction.

All in all i give it 4 thumbs up. Nice one!

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…