Anatomy of a CRM project - part two...
Continuing the walk through of a CRM project started in ‘Anatomy of a CRM project - part one':
Our original intent had been to include the support and service functions as part of the phase one deployment, but thankfully both we and the client concluded that this was probably biting off more than we had the joint capacity to chew, and delayed it to phase two. As an aside, many projects seem to benefit from being broken into a sequence of phases rather than a single ‘big bang’, because it allows you to concentrate your resources on winnable battles. A lot of project teams underestimate what’s involved in making the project a success, inadvertently take on too much, and get spread too thinly to achieve their objectives.
Anyway, during the six months or so that we were focused on getting the sales and marketing capabilities live, the world wasn’t standing still for the support and service teams. In fact, there were some significant changes, both of personnel, and in the way the teams operated. So as a starting point for phase two, the original 2004 analysis work needed revisiting and updating. Step number one therefore was to undertake some further business requirements analysis.
I think it’s appropriate at this point to note what I mean by business requirements, as it’s one of those terms that seems to mean very different things to different people. To my mind this process documents in a high level way the broad scope of the project, focusing on what it is within the business we are looking to improve. I get to see a lot of requirements documents produced by other people, and very few seem to identify the benefits they anticipate being delivered at the conclusion of the project. To the extent that requirements are documented, they tend to be long on functionality (must synch with my PDA, run on Oracle etc) and short on clear business objectives (increase our lead to sales conversion rate from 18% to 22% by….). Understanding functional requirements is important, but only in the context of supporting the achievement of the business objectives. We do spend a lot of time focusing on the detail of the functional requirements, but this comes a little later in the project.
In terms of this project, identifying precisely how the CRM system might benefit the support and service teams was key, because the attractiveness of the potential benefits ultimately would dictate what level of resources and funding (if any) the project would secure. The original 2004 work had picked up some potentially appealing productivity gains, through automating and streamlining existing working procedures, but these were not sufficient to guarantee the project going ahead.
The requirements gathering work was again conducted primarily through a series of one on one interviews focused on understanding current business processes, and identifying the potential benefit areas resulting from introducing new technology. This section of work took around four days, with two days spent with the client, one day on documentation, and one day presenting back.
As it transpired we picked up on quite a range of potential benefit areas during this phase. It was apparent from the exercise that the introduction of the CRM system could deliver a raft of productivity and customer service gains as well as a series of harder cost and revenue benefits. Without going into the specifics, our conservative estimate was that the system could deliver a decent six digit improvement to the bottom line each year. More importantly, in light of our findings, the client felt out estimates were conservative, and was happy to sanction the project on the basis of the associated project budgets. Interestingly, the projected pay back on the exercise repaid the cost of the project five times in the first year. Perhaps more interestingly, the magnitude of the pay-back was not apparent to either us or the client, before we undertook the exercise.
What we like therefore about the business requirements process, is that it’s a brief and cost effective way of assessing project viability, and allows us to map out and prioritise the broad scope of the project, without the client having to invest significantly up front. Sometimes, the outcome may be a ‘no go’, but then it’s better to realise a project isn’t viable before you begin it, rather than after you’ve completed it. Generally these exercises allow us to define a strong return of investment, and sometimes, as in this case, we identify a surprisingly high level of value waiting to be unlocked.
Having received the sign off for the project to proceed, we began a more detailed exercise to determine how existing business processes would need to be redesigned in the context of the new technology – but I’ll save that for a future post!
Our original intent had been to include the support and service functions as part of the phase one deployment, but thankfully both we and the client concluded that this was probably biting off more than we had the joint capacity to chew, and delayed it to phase two. As an aside, many projects seem to benefit from being broken into a sequence of phases rather than a single ‘big bang’, because it allows you to concentrate your resources on winnable battles. A lot of project teams underestimate what’s involved in making the project a success, inadvertently take on too much, and get spread too thinly to achieve their objectives.
Anyway, during the six months or so that we were focused on getting the sales and marketing capabilities live, the world wasn’t standing still for the support and service teams. In fact, there were some significant changes, both of personnel, and in the way the teams operated. So as a starting point for phase two, the original 2004 analysis work needed revisiting and updating. Step number one therefore was to undertake some further business requirements analysis.
I think it’s appropriate at this point to note what I mean by business requirements, as it’s one of those terms that seems to mean very different things to different people. To my mind this process documents in a high level way the broad scope of the project, focusing on what it is within the business we are looking to improve. I get to see a lot of requirements documents produced by other people, and very few seem to identify the benefits they anticipate being delivered at the conclusion of the project. To the extent that requirements are documented, they tend to be long on functionality (must synch with my PDA, run on Oracle etc) and short on clear business objectives (increase our lead to sales conversion rate from 18% to 22% by….). Understanding functional requirements is important, but only in the context of supporting the achievement of the business objectives. We do spend a lot of time focusing on the detail of the functional requirements, but this comes a little later in the project.
In terms of this project, identifying precisely how the CRM system might benefit the support and service teams was key, because the attractiveness of the potential benefits ultimately would dictate what level of resources and funding (if any) the project would secure. The original 2004 work had picked up some potentially appealing productivity gains, through automating and streamlining existing working procedures, but these were not sufficient to guarantee the project going ahead.
The requirements gathering work was again conducted primarily through a series of one on one interviews focused on understanding current business processes, and identifying the potential benefit areas resulting from introducing new technology. This section of work took around four days, with two days spent with the client, one day on documentation, and one day presenting back.
As it transpired we picked up on quite a range of potential benefit areas during this phase. It was apparent from the exercise that the introduction of the CRM system could deliver a raft of productivity and customer service gains as well as a series of harder cost and revenue benefits. Without going into the specifics, our conservative estimate was that the system could deliver a decent six digit improvement to the bottom line each year. More importantly, in light of our findings, the client felt out estimates were conservative, and was happy to sanction the project on the basis of the associated project budgets. Interestingly, the projected pay back on the exercise repaid the cost of the project five times in the first year. Perhaps more interestingly, the magnitude of the pay-back was not apparent to either us or the client, before we undertook the exercise.
What we like therefore about the business requirements process, is that it’s a brief and cost effective way of assessing project viability, and allows us to map out and prioritise the broad scope of the project, without the client having to invest significantly up front. Sometimes, the outcome may be a ‘no go’, but then it’s better to realise a project isn’t viable before you begin it, rather than after you’ve completed it. Generally these exercises allow us to define a strong return of investment, and sometimes, as in this case, we identify a surprisingly high level of value waiting to be unlocked.
Having received the sign off for the project to proceed, we began a more detailed exercise to determine how existing business processes would need to be redesigned in the context of the new technology – but I’ll save that for a future post!
posted by Richard Boardman at 2:59 pm
<< Home