Four years ago I was introduced to Salesforce.com when I took on a custom development project for a solar company. I have spent much of the last four years helping businesses succeed in implementing and adopting Salesforce.com. Without fail, the companies mirroring the basic philosophies and processes of Agile software development have a much better outcome. I’m convinced that Agile practices need to find their way into the best practices of CRM implementation.
Pre-2014 my professional life had centered on my boutique software/web development shop. I generally had one to three developers who worked for me, and always tried to follow a base form of Agile development strategies as a project management/delivery methodology. The shortlist of Agile bullet points are as follows:
Sprints: Time is divided into “sprints”, periods of around two weeks that are used as the units of planning.
Team Guided Planning: The team does its own sprint planning, with priority guidance from the product owner.
Team Guided Measurements: Tasks are given a size using a scale known as “story points”. They are intentionally arbitrary units of measurement and determined by group consensus.
Team Buy In: Individual team members proactively take responsibility for tasks they what to “tackle”. The team as a whole guesstimates and then whittle down the tasks for a sprint till the team feels comfortable the set of tasks is completable in the time period.
Small Groups: The team is small — 3 to 6 people. They can collaborate across tasks.
I want to look at each bullet point through the implementation lens. We will start with Sprints in this post. Planning & Measurements will follow as another post and Buy In and Group Size will round out as a third post making this a nifty little series.
Creating The CRM Archetype
The only thing worse than a three hour executive led strategy meeting where we discuss every aspect of the CRM archetype, is the followup three hour meeting (the third meeting is murder). Too often, executives unfamiliar with CRM serenity, believe outlining every single data point, process and workflow is a prerequisite to getting started. The twenty page bullet pointed magnum opus crafted in a word document, serves as the blue print I am to follow in while constructing a KPI expressive master piece. Upon my return, I will surely have anticipated any omissions and provide a spectacular CRM experience which is both easy to understand and yet comprehensive in its vast utility. The CRM will show the way!
As my teenage son says – “when you put it that way dad, it sounds dumb”. It sounds dumb because it’s a fallacy. Like software, a finely tuned company-wide system of processes and supporting tools is an aggregate of autonomous parts. In software, you very often can’t predict how a larger conglomerate process will function until the member parts are built and tested. The “Customer Journey” which should guide every aspect of the CRM implementation is divisible into the Marketing (discovery phase), Sales (education and decision phase) and Service (success phase) phases. These individual phases are further divisible and generally define actual department divisions within a company. It’s a lot to expect to outline it all in a single meeting.
Purposefully Guided Incremental Improvement
It can be very useful to divide implementation into finite amounts of time (sprints) and realize it will be an iterative process. These bounded time tables limit what can be tackled in the two week period. A well articulated Customer Journey will help keep sprint content relevant to overarching goals, but the time period will necessitate building and testing the processes and CRM configurations for a finite set of actions. As with software, creativity will increase when the subject matter is limited and defined. Each process will get better analysis and measurements specific to that process have a much better chance of being fleshed out during a sprint with finite subject matter.
Such an exhaustive system development roadmap sounds horrible to many executives because they are terrified 1) it will disrupt their business for longer and more intensely, and 2) it will drag out and cost more incrementally building finite segments of the overall system. This may be true. But most likely, laying a comprehensive semi conceived CRM system over an entire company is an inferior solution and some added disruption if done purposefully would have helped. The cost of not taking the time to get the Customer Journey support system right to begin with may manifest itself quickly in failed customer experiences or may never noticeably manifest because it was the high performance level that was never discovered.
We’ve explored why CRM implementation should be divided into purposefully guided incremental cycles/sprints of improvement. We briefly mentioned how this planning needs to be tied to the overall Customer Journey, and how incremental development can open the door to unexpected metrics. In the next post we will dive deeper into planning and measurements. The Agile methodology could add a lot to the CRM implementation and adoption experience.