What’s Not Included in Managed IT (What Becomes a Project)

Last updated

May 12, 2026

Reviewed by

IT Service Delivery Lead

Speakable Summary

Managed IT covers ongoing operations and support within a defined scope. Projects are one-time changes that modify systems or add major new scope.

Opening

Most conflict with IT providers starts with one sentence. “I thought that was included.”

Managed IT should reduce surprises, but only when boundaries are written in plain English. The goal is not to exclude everything. The goal is to separate day-to-day operations from one-time change work so approvals and budgeting stay clean.

This page explains what managed IT usually does not include, what becomes a project, and how to prevent scope disputes before they turn into surprise invoices.

Direct Answer

Managed IT usually excludes one-time change work that alters systems or adds major new scope. Projects should be quoted and approved separately to prevent surprise charges.

‍

What’s included vs what’s usually extra

‍

●    Ask for excluded scope in writing before signing

●    Require an approval gate before project work starts

●    Separate projects budget from monthly operations budget

Included means recurring work that keeps systems stable. Project work changes systems, adds new scope, or requires planned execution.

‍

Managed IT and project boundaries by support area

If you only do one thing this week

●    Ask your provider to define “project” in one paragraph.

●    Ask what is excluded in plain English.

●    Ask how approvals and quotes work before any extra work starts.

People

Managed IT typically includes day-to-day support for users and routine access changes. Projects usually start when the request becomes a larger rollout like a new department, a large hiring class, or a change that impacts many users at once.

Device

Managed IT typically includes routine device support, patching cadence, monitoring, and standard setup. Projects usually start when you are refreshing many devices, changing device standards, or migrating operating systems at scale.

Account/App

Managed IT typically includes routine administration for in-scope tools and standard access requests. Projects usually start when you are migrating platforms, changing domains, implementing a new major app, or redesigning permissions and structure.

Operations

Managed IT typically includes ticketing, documentation upkeep, vendor escalation, and consistent follow-through. Projects usually start when the work requires a planned design, coordinated cutover, or a major environment change that needs approvals and rollback planning.

‍

What usually becomes a project

Migrations and platform moves

Email moves, tenant-to-tenant migrations, fileserver to SharePoint moves, and cloud platform changes are projects. Theyinvolve planning, testing, cutovers, and rollback steps.

Office moves and buildouts

Moves involve cabling, equipment placement, new circuits, and physical testing. Even if support can coordinate vendors, the move itself should be scoped as a project.

Major network redesigns

Replacing core network equipment, redesigning VLANs, rebuilding Wi-Fi coverage, or changing firewall architecture is project work. These changes can create downtime if rushed and should be planned.

New system implementations

New line-of-business applications, new VoIP platforms, new backup platforms, or new security stacks are projects. Implementation requires onboarding, training, configuration, and validation.

Large remediation and cleanup

Inherited environments can have years of drift. If the work requires deep cleanup across many systems, it should be scoped as a project rather than “quietly absorbed” into operations.

Compliance and audit preparation

Audit packaging and formal compliance programs are often projects. Ongoing baseline controls may be included, but audit preparation is usually separate scope.

‍

‍

Common Questions

Do I need projects if I already pay monthly for managed IT?

Yes because monthly scope covers ongoing operations. Projects cover one-time change work and planned upgrades.

Do I need a separate projects budget?

Most SMBs benefit from a projects budget. It prevents emergency approvals and surprise spend spikes.

Do I need to approve projects in writing?

Yes because written approval prevents misunderstandings. It also protects timelines and expectations.

What’s the difference between support and a project?

Support keeps current systems running within scope. A project changes systems or adds major new capability.

What’s the difference between a small request and a project?

A small request is routine and repeatable. A project requires planning, coordination, and often affects many users or systems.

What happens if a provider treats everything as a project?

You will pay extra for routine work. A good scope document prevents that.

What happens if a provider never calls anything a project?

Costs appear later through emergency time and repeat failures. Clean project scoping prevents hidden risk.

What happens if we mix projects and operations together?

Approvals get messy and budgets become unpredictable. Separating them makes planning cleaner.

What happens if we need a migration urgently?

Urgency can happen after outages or vendor deadlines. A scoped project still prevents avoidable downtime.

What happens if we keep having repeat incidents?

Repeat incidents may require a prevention project. Standards and lifecycle work often belong there.

What happens if the vendor is causing repeated problems?

Vendor replacement is usually a project. Evidence and trend tracking should justify it.

What happens if we add a new location?

A new location often becomes a project. It involves networks, vendors, and physical setup work.

Can projects be phased to avoid disruption?

Yes most projects should be phased. Phasing reduces downtime and makes rollback possible.

Can project scoping reduce surprise invoices?

Yes because scope, price, and approvals are stated upfront. That prevents “we thought it was included” disputes.

‍

Key terms in plain English

Project: One-time planned work that changes systems or adds major scope.
Operations: Ongoing recurring work that keeps systems stable.
Scope: The work included and excluded in your agreement.
Approval gate: A required yes before out-of-scope work starts.
Change control: Documented approval and tracking for changes.
Cutover: A planned changeover from one system to another.
Rollback: Steps to reverse a change if it fails.
Vendor coordination: Managing escalation with third-party providers.

‍

Matching business needs to project scope

‍

Comparing operations, projects, and change size

Monthly operations vs project work

Monthly operations is recurring stability work. Project work is planned change that must be scoped and approved.

Small changes vs major changes

Small changes are routine and repeatable. Major changes require design, testing, and rollback planning.

‍

Copy/paste project scope and approval checklist

• Ask for an excluded scope list in writing
• Ask for a plain-English project definition
• Require a written quote before project work starts
• Require an approval gate for out-of-scope work
• Separate projects budget from monthly operations budget
• Require a timeline and rollback plan for migrations
• Track projects in tickets with clear owners
• Require closeout notes and documentation updates
• Review repeat issues monthly to identify prevention projects

‍

Common mistakes

• Assuming everything is included and fix it by requiring excluded scope in writing.
• Approving work after it starts and fix it by using an approval gate.
• Treating migrations as routine support and fix it by scoping them as projects.
• Mixing projects into operations and fix it by separating budgets and approvals.
• Skipping rollback planning and fix it by requiring rollback steps for major changes.
• Letting project decisions happen in side channels and fix it by tracking decisions in tickets.

‍

Common objections

We pay monthly so projects should be included. Monthly covers recurring operations not major change work. Projects need planning, approvals, and risk control.

We do not want surprise project quotes. Clear boundaries prevent surprises. A project definition and approval gate makes costs predictable.

We just want it fixed fast. Fast changes can create downtime. Phased projects reduce disruption and protect business continuity.

We do not want more meetings. Clear scoping reduces meetings later. It prevents long disputes during outages.

We are worried projects will never end. Projects should have scope, timeline, and success criteria. That is what closes them cleanly.

‍

What affects project scope and planning

• It depends on how standardized the environment is today.
• It depends on how many vendors and systems are involved.
• It depends on how urgent the change is and what cannot break.
• It depends on whether documentation exists or must be rebuilt.
• It depends on whether physical work is required on-site.
• It depends on compliance and retention requirements.

‍

How we separate managed IT from project work

We keep managed IT predictable by defining scope and exclusions in plain English. Tickets remain the system of record so requests, approvals, and outcomes are visible.

When work becomes a project, we pause and quote it before starting. We document what changed and why so operations become simpler after the project is done.

‍

How we measure project scoping and outcomes

• Number of out-of-scope requests per month
• Time from project request to approved scope
• Repeat issue rate before and after prevention projects
• Downtime risk during cutovers and migrations
• Documentation completeness after project completion

‍

FAQs

What is the simplest definition of a project in IT?

A project is one-time work that changes systems. It is planned, scoped, and approved separately.

What should always be treated as a project?

Migrations and office moves should be projects. Network redesigns and new system implementations should also be projects.

Can small businesses avoid projects completely?

No because systems change over time. The goal is to budget for projects and scope them cleanly.

How do we prevent surprise project invoices?

Require quotes and approvals before work begins. Keep a written excluded scope list.

Should projects be billed hourly or fixed?

Either can work when scope is clear. Fixed scope is often easier for budgeting.

When should we do projects during the year?

Plan projects around business cycles and deadlines. Avoid critical business periods when possible.

What should be included in a project quote?

It should include scope, timeline, and risks. It should also include what is not included.

How do we reduce disruption during projects?

Use phased plans and rollback steps. Avoid big bang cutovers whenever possible.

How do we know a project is complete?

Completion should be defined by success criteria. Documentation and closeout notes should be delivered.

What is a Fit Check?

A Fit Check maps your operations and what is becoming project work. It clarifies scope and next steps.

‍

Call to action

If you want clean boundaries between monthly support and project work, book a Fit Check. You will get a plain-English scope map, a project boundary checklist, and next steps you can act on.

‍