To know what “out of scope” means, you must first understand what defines a scope of work.

“Scope” is a project management term frequently used in software development. It refers to the agreed-upon and outlined work within a project. Typically, the company offering the service creates a scope document outlining what needs to be completed and shows it to the paying client, and both agree on the specifications. The scope is the work the service company should deliver to achieve the client’s project needs. 

Creating a scope puts bumper lanes on a project. It helps all stakeholders align their understanding of project requirements while stating the criteria outside the project’s objectives. 

A company that provides IT security could document a scope of work by writing down objectives their employees need to complete per request by a client who needs a more secure system. The scope document could state that the service company will set up email encryption and extra layers of database security but will exclude cloud migration work. 

Exclusions take us to our next point—what counts as ‘out of scope’ within a project. 

What does ‘out of scope’ mean? 

Anything ‘out of scope’ refers to work crossing beyond the outlined framework of the project. These tasks are determined unnecessary for the project’s successful outcome. If the requirements are well documented, deciding what specifications fall outside the project parameters should be easy, making those out of scope.

For example, imagine a client approaches a managed IT service professional asking for help setting up a new email system for the client’s company. In-scope elements would include selecting an email platform, configuring the servers for security and performance, and ensuring data migration from the previous system, as these are all directly related to the project’s core objective. 

Conversely, setting up a new customer relationship management (CRM) software would be considered out of scope. Though potentially valuable and possibly even interoperable with a new email system, standing up a CRM doesn’t directly contribute to the success of the updated email system. 

Out-of-scope specifications don’t imply a requested service or feature is unwarranted (or the provider can’t develop it). It simply means it won’t be addressed in this specific project.

What makes a task out of scope?

There are many valid reasons why something is outside a project’s scope of work, such as:  

  • Only one of the provider company’s multiple services could be requested, leaving the remaining services out of scope. 
  • A criterion was intentionally removed from the original scope document.
  • The client has limited resources and wants a small, restricted project.
  • The requested work isn’t relevant to the key initiative of the project, so it’s backlogged.
  • There is a strict timeline, so the project will prioritize high-impact features and slate the rest for future projects. 

Clarifying exclusions to a project and getting stakeholder buy-in for what is out of scope is just as important as defining what is in scope. Having a framework that clearly defines what is in versus out of scope makes it easier for employees to know what is expected of them and for clients to understand what is being delivered. 

In scope vs. out of scope

In-scope requirements are specific to the client’s request for the project at hand. These parameters must be met for a project to be completed. 

Out-of-scope work—called “scope creep”—is when a new aspect of the project not initially included in the scope document is introduced. Scope creep could involve adding a new feature, increasing the number of deliverables, or extending beyond the established timeline. Anything not in the signed scope documentation can be considered out of scope. Having thorough discovery and SOW documentation can help minimize scope creep by accounting for all aspects of a project, ensuring nothing is accidentally overlooked. 

Examples of out of scope

What’s in scope for one project can be out of scope for a different one. However, a few categories are commonly associated with scope creep within IT and software. 

  1. Adding new features: Requesting the development of new features that weren’t included when the project’s technical specifications were agreed upon would be considered out-of-scope work.
  2. Changing budget allotment: Deliverables can hinge on the client’s budget. If a client agrees to use a cheaper email client for the business but later changes their mind and wants to use a more expensive email software, it could cause scope creep and the potential to go over budget.
  3. Changing the number of deliverables: It doesn’t need to be a new feature, as simply increasing the number of existing deliverables is an example of out-of-scope work. For instance, changing the quantity of software user types can cause a significant increase in development costs. Even a customer doubling the requested hardware installs in an office from two to four would change how a service is provided, cost, and timeline. These are out of scope because they weren’t in the original agreement.
  4. Iterations on functionality: Some projects take months to complete. During that time, a client might change their mind on how they want a feature to work. Asking to update or change a feature while the project is ongoing is a new facet, trying to force the initial scope to include what is out of scope. 

To help make in vs out of scope more tangible, let’s use the example of a legal firm needing infrastructure improvements. 

Project scope example: IT service infrastructure

A client from a mid-sized legal firm approaches an IT service company requesting upgrades to their current infrastructure. They want to improve security and remote work capabilities, given the need for their staff to work from various locations. The IT service company discovers the client’s needs and then makes a statement of work outlining the project’s scope.

In scope examples

  • Network security enhancements: Implementing firewalls and encryption to protect sensitive client data from unauthorized access. 
  • Cloud storage: Setting up and migrating data to allow secure remote access to company files.
  • VPN access: Configuring a virtual private network (VPN) service to safely enable remote connections to the firm’s network. 
  • Two-factor authentication (2FA): Instituting 2FA as an extra layer for security before remote workers access the firm’s critical systems.  

Out-of-scope examples

  • Office hardware upgrades: Upgrading in-office hardware, like printers and workstations. 
  • Custom legal software development: Creating specialized software related to case law research and case management. 
  • Website redesign: Overhauling the firm’s website to improve UI and user engagement. 

How to avoid scope creep

Conduct clear discovery

Sometimes, a delivery team assumes they know what a client wants, only to find out mid-project that those assumptions were incorrect. Before kickoff, service providers and clients should thoroughly discuss all needs and priorities. Doing so can prevent double work and reduce scope creep. 

Get stakeholder buy-in

Using a written scope document, all stakeholders should review the specifications and ensure teams feel aligned on the work’s direction, process, and outcome. Documenting the client’s requirements will help them feel heard, promoting their support of the project’s direction. It’s just as essential to make sure the product team has buy-in and shares their thoughts on the work. This way, any potential hiccups can be addressed. 

Write detailed documentation

Vague phrasing in scope documentation can leave stakeholders with different expectations. An IT professional might add “integrating CRM with email marketing platform” to connect the two services so the client can create email lists and campaigns from conversion points. The client, however, might assume that part of the integration service includes upgrading the CRM to better structure how it displays tracked data. 

Hazy phrasing and unclear documentation leave deliverables open to interpretation, causing inefficiency and scope creep. Writing clear and detailed deliverables and expectations can align teams to shared goals, focusing all energy in one unified direction. 

Account for flexibility

When estimating complexity, time, and effort in a software development project, the safe move is to build in a little room for variance. Developers might encounter an unexpected hitch when looking into a new API and need an extra day to sort through the code. Accounting for variance upfront will keep clients from being surprised if a small hurdle does arise.  

Define each deliverable

As well as discussing specifications to be completed, such as which features to include or what hardware to install, ensure timeline and cost are addressed. These factors determine which elements are in or out of scope just as much as feature and service needs. 

Establish priorities

When discussing a client’s project goals and outcomes, take the extra step to define what is considered a ‘must have’ or a ‘nice to have.’ When coming down to the wire, it could be that the client is happy removing some ‘nice to have’ features and focusing more on the ‘must have.’ Spending time during the discovery stages to flush out all priorities and high-value/low-value efforts will create a tighter scope of work. 

Assess project milestones frequently

Internally running retrospectives assessing quality, resource allocation, and timeline can ensure teams stay on track and complete the in-scope requirements. Don’t assume everything will be done under budget and on time. Stay in constant communication with clients about project status so they are up to date. 

Automate when possible

Mistakes happen. Complex project estimation increases the chance that a facet will be forgotten during scope discovery. For example, Cisco provides such an extensive suite of services that an engineer scoping the work to overlay cloud principles on a client’s IT stack might forget to include an essential implementation specific to data center networking. Using programmatic solutions and having matter experts create the scope can prevent forgotten specifications. 

Scope creep vs. gold plating

Scope creep is most commonly initiated by the client asking for something new, different, or bigger mid-project. As the name suggests, it can sometimes sneak up on a delivery team as the scope of work has crept beyond its original size.  

Gold plating still involves a project expanding beyond its parameters, but the cause differs. Gold plating occurs when the delivery/product team takes the liberty to add extra features or enhancements without consulting the client. It can come from a well-intentioned place, like wanting to give the client a surprise bonus feature. Still, it often runs a high risk of skewing resource allocation and negatively impacting delivery dates if that feature wasn’t desired for a specific reason. 

Example of gold plating

Using the example of the legal firm’s infrastructure upgrade project from earlier, let’s say an IT technician, with some extra time, decided to implement an advanced AI-based document analysis tool that wasn’t included in the initial project outline. The technician believed it would help the legal team analyze documents more efficiently. 

Upon presenting to the client, the IT team learned the firm was not ready to adopt an advanced new tool due to having limited time to train staff and concerns about how this technology would impact their existing workflows. Consequently, the IT team had to remove the AI technology from the legal firm’s system, which delayed the completion of the infrastructure project. The setback frustrated the client, who simply wanted to improve remote work capabilities without complicating their current operations. 

Beyond impacting deliverables, when gone wrong, gold plating can erode the trust between the service provider and the client. It’s why project management cautions against this technique and instead encourages strict adherence to the agreed-upon scope of work. 

What is scope change?

Sometimes, there are valid reasons to allow a scope of work to iterate after a project kickoff to meet external criteria. A scope change is when this iteration is formally accepted into the project specifications.

A VC investor may ask for specific features (slated initially for future versions) to be bumped up to the first launch. Similarly, an IT team has a project upgrading security infrastructure for a healthcare provider. In the middle of the project, new strict healthcare data regulations were introduced, so the project must adjust the work required to ensure the healthcare provider complies with the new rules. The company must change its ongoing project to comply with these new regulations. 

How to approach scope change

Scope changes can be incorporated into a project through a change management process. If the estimated scope included some variance, then ideally, resources, time, and budget aren’t impacted by iterations of the scope. The key is accommodating intentional and meaningful alterations while preventing unnecessary scope creep.

When a scope change occurs, it’s time to baseline the project. Update the project plan to include the new changes, accounting for cost, resources, and scheduling differences. It will cause a mess down the road if the tangible deliverables don’t match the project work breakdown structure or written scope. 

Finally, make sure to stay in constant communication with stakeholders. So many mistakes can be avoided if clients are continuously updated. It makes all those involved feel aligned and can clarify any misunderstandings before they grow into a problem. 

Adhering to scope is only one part of IT project management, but it is a big one. Maintaining a strict scope of work, preventing scope creep, and processing scope change can be the difference between successful project completion and never seeing the light of day because it couldn’t get traction. 

Fight scope creep with ScopeStack’s CPQ software and SOW 

ScopeStack is a platform built with managed IT professionals in mind. Preventing scope creep and keeping an IT project under budget and on time can get tricky even for the best-managed service professional. Use help and automation when you can get it. 

ScopeStack’s CPQ software generates custom and exact quotes for each client’s project needs. It saves your team time, freeing them up to do the work they’re best at while creating a straightforward document that can be used to get stakeholder buy-in. Plus, the SOW template library can help with delivering top-notch statements of work. 

Contact us to learn more about how ScopeStack can benefit you.

You may also like: