Ever got stuck with round after round of requirements gathering and yet you feel no closer to getting stakeholder consensus? How about months of development close to go live, only to find your hard work wasted as the business has changed direction or process, rendering your deliverable obsolete? How can we avoid these pitfalls and deliver CRM projects with business impact?
CRM Projects Driving Behavioral Change
CRM Projects, like many other IT projects which are people-oriented, are typically hard to deliver. This is because you ultimately want the software to deliver a change in peoples’ behavior. For example, you might wish to implement Dynamics 365 for your customer service team to streamline complaints management processes and improve case resolution times. What you are likely aiming for using Dynamics 365 to support your customer services representations in their dealings with the customers. Perhaps you wish to provide the team with e.g. full customer history view and accounts details, so the contact staff avoid accidentally aggravating customers with repeated questions the customer has already provided. You want a system that collates and displays these customer background information so that the customer service staff can adjust their behavior/interaction accordingly.
So far so good right? How can this kind of feature requirement possibly lead to failure or low user adoptions?
The key in my opinion is to understand by HOW MUCH you want the staff’s behaviour to change? In other words, what is the success metric that you can use to judge if a delivered feature has now produced improvement significant enough that you can stop with the change and target another feature? If you do not intend your feature to produce significant change, why are you investing in this? How does this route help your business strategy?
After all, as the CRM Manifesto states, CRM is a “business strategy”, and that “deploying a CRM system will not, by itself, improve sales and drive customer retention”.
So, what is your business strategy and how do you plan to deploy CRM to support this?
Why Do IT Projects Fail?
Actually, the difficulty in setting business goals and tying the “big picture vision” to all the detailed tasks, requirements and plans in an IT delivery is not a problem exclusive to CRM projects. It is a problem that many IT projects struggle with in general. For example, the recent Harvey Nash/KPMG CIO Survey highlights that project “success rates are falling”, driven by problematic areas including:
- Weak ownership
- Unclear objectives
Dive a little further other surveys such as PMI’s “Pulse at Work 2017” and you will see identified gaps such as communications and business requirements gathering:
“39% of organisations … say that inadequate requirements gathering is the primary cause of project failure, while 30% cited inadequate vision or undefined goals for the project….”
Requirements gathering? I hear you asked. Perhaps you then say that in our agile project we have business analysts and product owner who collaborate to work on requirements. So why would there be any gaps in requirements analysis leading to project failures?
Scrum and the Product Owner
So here’s a diagram describing the Scrum Framework that I often refer to when talking about the different tasks and team member responsibility.
The “Product Backlog” is a list of all user stories and requirements that a Product Owner provides to the Scrum Team (think of it as a giant wish-list of all software features the business wants). The important key here is that this product backlog must be prioritised by the product owner in order of business values, before the scrum team moves high value items to sprint planning sessions.
But here’s the problem, how does a product owner decide on this prioritisation of the backlog items? Things get even more complicated if the business contains many stakeholders and SMEs, all of whom might have competing wants and needs. Being a product owner means juggling expectations and making judgements on how best to achieve business goals with selected product backlog items, against the backdrops of competing voices across the business.
Unless a product owner is empowered to make these hard choices, very quickly he/she might find themselves in a tangled situation where all product backlog items are deemed “must haves” by the business. Scope increases, complexity increases, delivery time increases, and it becomes difficult to judge if you might have over-delivered/over-invested for a business goal, or which feature (among all the must-haves) are actually the most effective in driving the required business change.
Impact Mapping is here to Help
Impact Mapping is a “collaborative strategic planning technique” that helps visualise the scope and underlying assumptions in your IT project. If you haven’t read Gojko Adzic’s book “Impact Mapping: Making a big impact with software products and projects” I would highly recommend it.
At the heart of impact mapping you address 4 key questions
- Business Goal – WHY are you doing this?
- Actors – Who are the people you want to impact or influence?
- Impact – WHAT kind of impact or change do you want to see in your actors?
- Deliverables – HOW do you support the required impact, to achieve the business goal?
The answers to these 4 questions are then lay out in a diagram (as below). This gives you the visualisation that ties all deliverables (e.g. user stories, requirements, documentation etc) to the business goal. This explicit visualisation provides context, helps prevent scope creep and over-engineering of solutions design.
A CRM Project Example with Impact Mapping
Suppose a Professional Cleaning Company would like to implement Dynamics 365. The executive sponsor believes that implementing Dynamics 365 will help the business better manage customer base and win more new cleaning contracts.
Remember I said at the beginning that CRM projects drive business and behaviour change? It’s important here to find out from the sponsors just HOW MUCH change is required of the implementation for it to be considered a success comparing against current operation? Without quantifying this change (e.g. defining this success metric), you will not be able to come up with plans to measure effectiveness of future software releases, to make future informed decisions on what to do next.
Let’s supposed in our example the executive sponsor decides that the success metric for the new Dynamics 365 implementation is to deliver 20% more wins to new cleaning contracts. This gives the requirement gathering meetings with business stakeholders a goal to aim for. Furthermore, the SMEs identify several groups of “actors” who can support this goal, one of which is “new leads” (businesses who have not used the cleaning service before). Marketing SMEs believe that the business’s current competitive pricing of cleaning services is the main driver for new engagements, while Sales SMEs thought that personalised cleaning contracts is what closes more new deals. Further exploratory decisions help map out some of the other groups of actors, impacts and deliverables involved.
Eventually you might end up with the following impact map for this cleaning company…
Here are some of the ways you can now use this impact map to drive further decisions …
Impact map is a great visualisation tool to help keep everyone focused. All deliverables on the right hand side are tied to a business goal on the left. It’s often that a brain-storming session might generate ideas for features that seem like “must have’s” initially. Without business justifications, it’s incredibly difficult to argue for or against the inclusion of a contentious product feature. This keeps the overall scope tightly focused on the stated business goal of e.g. “winning 20% more new business”.
Remember earlier in this example Sales and Marketing SMEs differed in their opinions on how to influence more new leads to sign up for cleaning contracts? That’s why we have multiple options in the “Impact” column tied to “New Lead” actors, and each “impact” option is tied to multiple deliverables supporting the impact.
Actually, every single link in the impact map represents an “assumption” at the beginning of project delivery. You won’t know definitely until you have delivered the CRM project and measured against the success metric, that the assumption is actually correct.
For example, we assume that an easy online search functionality (deliverable) that exposes the competitive service pricing (impact) would influence new leads (actors) to sign up for new cleaning contracts (in support of the business goal). Similarly, we also assume that a mix and match service (deliverable) that allows new leads (actors) to personalise their service requirements (impact) would help win new business (goal).
By calling out these assumptions in the impact map, it provides a way of scrutinising these assumptions throughout the project. If the underlying assumption is no longer correct due to e.g. changing business environment, why are you still planning to deliver the associated user stories/features?
If you have multiple options (actors, impacts, deliverables etc) that we assume will suppose a business goal, it is important to realise that perhaps not all deliverables must be completed to support a business goal. This helps avoid the “All requirements are MUST-HAVES” scenario.
Equally important is the prioritisation of impact, and hence deliverables (right hand side of the impact map) so we have a curated product backlog ready for sprint planning. This is where you need to consult with the SMEs for their experience and business histories to help prioritisation. For situations where there is just no clear choice, can a Proof of Concept be proposed to validate the underlying assumptions before committing to full sprint and deliverables?
For example, let’s say the Cleaning Company wants to validate the idea that a personalised cleaning service helps win more new business. Instead of committing to delivering this new feature immediately in the next sprint (which can be quite complex to design), how about testing this assumption first by having the marketing/sales team advertise a mix and match service over a period of time to gauge its likelihood of influencing new leads to sign up? Once you know the likelihood is high, talk to the delivery team on the detailed personalisation requirements.
Ideally the aim is to help the business figure out WHAT to invest in rather than simply “do it all”, to prevent over-investment of a business goal.
Remember the 20% more new business as the success metric? If you measure this before and after a feature is delivered you will know whether you have achieve the objective afterwards. For example, the team chose to prioritise the “mix and match” personalised service to be delivered. If you now have 20% new leads signing up after this feature is realised in Dynamics 365, great! You don’t need to the team to deliver e.g. the online pricing search. You can move onto other business goals or objectives.
Conversely if the chosen deliverable does not generate the assumed impact, stop! Choose an option that are visualised in the impact map.
Impact mapping is a great way of visualising scope, checking on assumptions and provide ties between the big picture (business goals) to all the detailed tasks (deliverables) that are carried out in a IT project. It helps generates conversations with everybody on the business and project teams and supports a product owner in prioritisation of the product backlog.
If a CRM project is to succeed, it is important to have clearly defined objectives and success metric from the start of the delivery. I believe techniques like impact mapping can help.
Now that you know what impact mapping is, how do you plan to use it?