5 Reasons Why SPM Projects Fail
Sales Performance Management (SPM) projects are complex and most don’t complete on time or within budget. As a specialized SPM services firm, Spectrum has worked on numerous SPM implementations with a variety of technologies. The following our five of the top reasons why SPM implementations run into issues and our take on what can be done to mitigate those risks.
# 1 – Lack of Executive Sponsorship
SPM projects involve participation from multiple business functions like Sales, Finance, HR, Legal et al. There is always a possibility of participants losing momentum on project tasks, as they also need to focus on other regular job. The presence of a senior leader as an Executive Sponsor of the SPM project, who everyone looks up to for directions and guidance, helps in keeping the focus of the team on the project priorities.
Decision making in a multi-dimensional team comprised of mid-level managers is a challenge. The project runs into time pressure frequently. The executive sponsor understands the success factors and constraints too well. With the authority to take quick decisions, he helps aligning the team to his directives and ensures that timelines are met.
# 2 – Poor Project Governance Model
Since multiple functional departments have participants in the project, involving all the stakeholders throughout the life cycle of the project is an absolute necessity. A consistent, proactive and methodical communication platform ensures that the all the stakeholders are well informed of all the elements of the system that are being impacted during the project. It is important to form the steering committee very early in the project that lays down a simple and transparent project governance model, identified the dependencies and risks in the project, establish a versatile project plan involving all stakeholder participation and a sound communication platform that keeps the directives clear.
# 3 – External Dependencies
SPM projects impact multiple functions such as Sales, Finance, Legal, HR, IT etc, and at the same time get impacted by multiple functions. This puts SPM projects at high risk, especially the projects with long project timelines.
Several external factors like – a new executive, launch of a new product line, an M&A announcement, economic downturn or legal lawsuits, can very quickly bring in significant changes to business processes, incentive plans and resource availability. The new VP of Sales walks in with new visionary ideas that put the in-flight project back to design phase! An enhancement applied to ERP system breaks the data interface and so on.
It is important to realize that SPM projects are not happening in silo. There are lots of dependencies! While it is impossible to predict the unforeseen, one has to put in a conscious effort to look beyond the horizon and anticipate the factors that may impact the project. If there are too many changes expected in the near term, you should consider pushing out the project kick off.
# 4 – Poor Resource Planning
Operational and project responsibilities are different, and it makes sense to keep them separate.
Can the driver of the car also be made responsible for engine tune up? Yeah, maybe, but generally you wouldn’t expect one person to take on the dual role. However, in SPM projects, we often see the commission operations team carrying on the added responsibilities for supporting the new project, especially testing. This leads to severe operational conflict with project tasks.
Like any other complex projects, different specialists are needed to be assigned to specific roles. Bigger the project, greater will be the resource needs. If it is so deemed that operational team has to be the one doing testing as well, then one has to plan for the month/quarter ends, when operational team would have no bandwidth for the project. Don’t assume 100% availability.
Planning of vendor resources is also important. I have seen projects where multiple vendor resources are on-boarded on the project kick off, even though the ground work of the project is not yet completed! It’s like getting construction workers on the ground when the floor plan is not even approved. This burns a lot of money over idle vendor resources causing budget crunch for later phases of the project.
# 5 – Testing Approach
Most popular testing approaches are – Parallel Run and Test Case based testing. Most often there is not much thought given to which approach is best suited for the project.
Parallel Run approach requires running the legacy (or current) system in parallel with the new (or enhanced) system, and comparing the results for a quarter or two. This approach does not work, if there are significant changes in the plan design and expected results. I have seen testing resources working arduously to identify and explain the gaps between the two systems. If the new plan design is very different, or the old system has lots of known issues, then why waste time in doing reconciliation! In such a situation, test case based approach is more suitable. However, building numerous test cases, test data, and expected results, is a time and effort intensive approach.
One needs to evaluate the two options, and take a conscious decision on which testing approach is most suited. Very often a hybrid approach works much better. Compare the results with the old system where there are no changes, and build exhaustive test cases for some selected modules.
About this Blog’s Author
Maneesh Gupta is the founder and Managing Partner at Spectrum Technologies. Spectrum is a Silicon Valley firm providing specialized services in the area of Sales Performance Management Systems since 2006. Maneesh can be reached at firstname.lastname@example.org