A Good Plan: Avoiding Scope Creep

 

a-good-plan-scope-creep.png

In this guest blog series, Anaplan partner Spaulding Ridge will examine what they have found to be integral parts of a good plan: the level of detail, the process, the people involved, the timing, and pitfalls to avoid.


Now that you have decided the level and type of detail in your planning process that works best for you, the next item to consider is the content of your plan: what is the scope?

When we talk about “scope,” we’re referring to the clearly-defined goals and boundaries of the project: what should it accomplish, who does it affect, and how will we accomplish it?

There are many different factors to evaluate when looking at the scope of your plan. Invariably, each of your organization’s plans should influence one another; however, different areas of your organization may be better or worse prepared than others to innovate. Additionally, while data may be sent between different groups to develop an organization-wide plan, this data still tends to be siloed, caused by a lack of interaction between those groups.

There are two scenarios to consider that, for the purposes of scoping, can be treated very similarly: not having a planning process or having an inadequate planning process. Both require action and merit many of the same treatments.

In this post, we will examine how to think about the right level of scope, and specifically address the concept of “scope creep” and how to avoid it in your planning process.


More Planning Tips:


The Classic Mistake

The single largest mistake I have seen companies commit in the process of planning innovation is trying to do too much at once. Companies may periodically realize that they have broken or missing processes but usually each individual realization does not merit strategic intervention. This eventually results in a type of snowball effect as these ailing or missing processes are finally identified and targeted for improvement, usually culminating in a broader project that is intended to be a solution for all of an organization’s planning woes. While this is not necessarily a bad idea, the execution of this initiative frequently derails the overarching planning process.

Case Study: Too Much, Too Soon

I worked with a client who had identified a relatively large improvement need in their sales performance management (SPM) process. They identified needs in their sales transaction storage/analysis, sales crediting, incentive compensation plan structure, commission recognition, and visibility into incentive compensation. To remedy this, they invested in Anaplan and a partner to advise on business process improvement. Up to this point, all was well and good. However, they then decided to not only improve all of these areas simultaneously, but to also introduce quotas to the organization, which was something they had never had before.

As I had never undertaken a project of this size and scale before, I did not know that I should have raised a big red flag, but I soon learned that lesson: by project’s end, I estimated 20 percent of my time had been spent simply keeping the core team aligned in communication—that’s not Anaplan development, nor training, nor meeting with SMEs, nor testing, nor any other activity; it was simply keeping people aligned because of the vast scope. Trying to do too many things at once introduced significant complexity and cost precious time. Keeping that many people building in Anaplan (ten!) and who are subject matter experts outside of it assisting on the same page was an onerous task.

To layer on top of it, we discovered that introducing that level of change that quickly to end users was too much for the organization to handle. As a result, we had to introduce delays in order to gradually phase in the rollout of Anaplan.

Setting Boundaries

This episode taught us that technology is closely tied to business process. If you change one, you invariably change the other one. As humans, we can adapt to change, but we can only adapt to a certain rate of change. Although many (or possibly all!) may recognize the need for change it is generally unwise to try to change everything at once. Beginning with a single, focused new planning process yields phenomenally better results.

If you have worked with Anaplan for any length of time you know how revolutionary a tool it can be in your planning process. As with any new tool, however, it takes time to learn, to use, to administer, and to integrate into your organization. Just like repairing a ship at sea, wisdom tells us to replace parts piece by piece rather than all of them simultaneously.

Focusing on a single use case and ensuring its unequivocal success will go a long way toward your big-picture strategy of process improvement. In the same way, once people experience the success of a targeted use case, the infrastructure and confidence will be in place for you to take planning improvement to the next level.

How have you refocused the scope of your project to ensure success? Leave a comment below and let us know!


aaron-overfors.pngAaron Overfors, manager in performance management at Spaulding Ridge, LLC, has been working with the Anaplan platform for five years in various roles at Anaplan and Spaulding Ridge, including product support, customer success, premium support, and solution architecture. He has extensive experience working in sales performance management (SPM) use cases of Anaplan and couples it with his deep knowledge of the Anaplan product to help companies construct more robust plans that engage stakeholders and deliver tangible value across their organizations in a dynamic competitive environment.

LinkedIn: Aaron Overfors | Spaulding Ridge

Tagged:

Comments

  • Brilliant post. Can't stress enough how prevalent "trying to do too much at once" can be!

  • @aaron_overfors great blog post.

    I've found the Anaplan Way to be a good way to put up some guardrails to ensure projects are manageable. While most implementations I've been on shy away from this, I have also found that the planning poker is a good idea too, especially if you are working on a large team.

    Thanks for sharing this blog! Nicely handled.