Managing Scope Creep in CRM Projects
CRM implementations are like any other project that involves managing resources available and satisfying the stakeholders. So what can be done to better the chances of the success of a CRM system implementation? Are all the success factors dependent on the system vendor and implementation? No. In fact, most of the success factors lie in the softer areas of managing expectations and scope of the project.
What is meant by scope of a project?
Every project is executed with an end result in mind. Every project has a preset (expected) closure time. Within this closure period there is a predetermined set of tasks and activities that need to be completed. These are tasks required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. These tasks constitute the scope of a project. Since a project schedule is closely tied to the delivery time line and the scope, a little variation in the scope can affect delivery and in turn affect the success perception of the project (not taking into account the costs).
This inching forward of scope to introduce more requirements (not included in initial planning) in the same time frame of the project delivery is called scope creep. It is a real danger to most system implementations, be they CRM or any other projects. Most project managers build a buffer in their plan to include a certain percentage of scope creep so that the overall delivery remains unaffected. In the end, it becomes a decision on what requirements can be accepted and what cannot be accepted as a part of the project. A project manager walks on a tight-rope by being branded antibusiness on one side if he is too resistant to scope creep, and being branded an unsuccessful project manager on the other side if he allows the project schedule and cost to be impacted by allowing too much scope creep.
Why does scope creep occur?
Systems help solve business needs for a company, but business is dynamic--there are continual changes in the operating environment that affect business processes and decisions. This also impacts changes in the business need from the system.
One of the more common reasons for scope creep is insufficient requirement analysis, wherein a lot of hidden needs are not identified. These later come out during the lower level design when the hard choices on low level process designs are made. So, how do we manage scope creep and improve chances of project success? There are some very simple things to keep in mind to allow for better management of scope creep:
1. Set project expectations with the customer stakeholders.
2. Decide and document the agreed project deliverables and requirement areas that are NOT included.
3. Document requirements and review with the customers before any sign off.
4. Decide and document how the users will use the system (in fact, get test cases from the users at the requirement analysis phase).
5. Make a flexible project plan allowing users to participate at the design phase and incorporate their suggestions. In case scope creep cannot be avoided, participate in rescoping.
6. Introduce a formal change management process that makes users asking for more functionality accountable for the demand. (It is surprising how effectively this cuts out low priority demands, when users have to initiate a change requisition.)
7. Do an impact analysis and attach a cost and time to work on the new creeped-in requirements. This is effective in getting the sponsor to revalidate the new requirements.
About the Author
Vishal Sarkar is a senior CRM consultant with international experience, now at GrapeCity in Seattle. A regularly published author, he specializes in CRM technology solution deployments: business analysis, CRM strategy, and process definition. He has consulted for companies across industries in China, Hong Kong, India, Japan, UAE, and the United States. He has a passion for customer service and management, and his professional interests include change management, people development, and a push for lateral thinking.