By Michael Brown 1

Scope creep can be disastrous to a managed service provider delivering cloud-based file sharing — and is one of the major reasons why a service level agreement is so imperative. Scope creep can occur either due to internal or external drivers, but either way it is almost always detrimental to the system as a whole.

Understanding how scope creep happens and how you can manage it can help you keep your cloud projects on track and under control while still keeping your clients happy.

What Is Scope Creep?

Scope creep generally occurs when a service has been poorly defined or undocumented. The cloud services that an MSP provides will slowly begin growing and becoming more cumbersome, as either management asks, "Why don't we have this feature?" or customers ask, "Why can't you do this for us?" An example of simple scope creep would be a scheduling service that the MSP doesn't actually provide. Once a customer asks for it, it can seem trivial for the MSP to "expand their scope" and request that a technician program in a scheduling service for that one customer. Sounds like great customer service, right?

Unfortunately, because this is crept scope and not established scope, the scheduling service now exists outside of documentation and control. It is likely to be poorly supported. The customer may run into issues with it and consider it an issue with the managed service provider, even though the MSP didn't include this in their service level agreement to begin with. Technicians may also find that dealing with the service is a "hassle," because it isn't part of their ordinary job — even though they added the service themselves.

How Do You Manage Scope Creep?

Scope creep is appropriately managed through thorough documentation and controls. Nothing should be added to the scope without careful consideration and it should always be added as a universal addition to service rather than on a case-by-case basis. In the above example, it would be appropriate for the company to consider adding scheduling services to their core package and, if they found it to be useful for their customers, they could then added it in a well-developed, rigorously documented fashion.

But scope creep doesn't always come from external forces such as clients, so service level agreements aren't the only way scope creep needs to be managed. There are internal pressures that can lead to scope creep as well; a sort of "Why not add this?" philosophy. On that level, careful controls need to be created for managerial interference, service additions and scope expansions. Just as too many cooks spoil the broth, too many technicians will spoil the IT. It should be clear that services and scope can only be altered through very clear protocols.

Scope creep can quickly destroy the quality level of a managed services provider. As the scope expands, fewer cloud services are done well, and some services that are provided may not work as they should at all. Technicians become harried and customers become frustrated and confused. But scope creep can be controlled by stricter scope management and service level agreements.