Contract Strategy

Defining "Project Work" vs. "Maintenance" in Fixed-Fee IT Contracts

The most contentious invoice you will ever receive from an MSP is the one for work you thought was included. Here is how to draw the line before you sign.

In the negotiation phase of a Managed Services Agreement (MSA), both parties are optimistic. The client hears "unlimited support" and imagines a flat monthly fee that covers every technical interaction. The provider hears "standard maintenance" and assumes they will only be responsible for keeping the existing lights on.

This misalignment creates a predictable friction point six months into the engagement: the "Scope Creep" invoice. It typically arrives after a seemingly routine request—like upgrading a server operating system or onboarding a new department—triggers a billable project code.

To avoid this, procurement leaders must understand the operational distinction between Maintenance (keeping the current state functional) and Projects (altering the state to add value). This is not just a semantic argument; it is a financial boundary that defines the profitability of the contract for the provider and the cost predictability for the client.

The "State Change" Rule

The most effective heuristic for distinguishing maintenance from projects is the "State Change" rule. If a task restores an asset to its baseline performance (e.g., rebooting a frozen server, patching a security vulnerability, replacing a failed hard drive), it is Maintenance. It is the cost of doing business for the MSP.

However, if a task introduces a new capability, changes the architecture, or requires significant planning to execute without disruption (e.g., migrating to a new cloud tenant, deploying a new ERP system, moving an office), it is Project Work. It adds net new value to the organization and falls outside the fixed monthly fee.

Chart visualizing the boundary between Maintenance and Project Work based on complexity and risk
Figure 1: The "Friction Line" represents tasks that are technically maintenance but carry the risk profile of a project, often leading to billing disputes.

The Grey Area: Where Disputes Happen

The chart above highlights the "Friction Line"—the zone where definitions blur. The most common disputes arise from tasks that feel like maintenance to the client but require project-level resources from the provider.

OS Version Upgrades: Upgrading Windows Server 2019 to 2022 is technically "maintenance" (keeping software current), but it carries high risk. It requires backups, testing, and potential rollback plans. Most mature MSAs classify major version upgrades as billable projects due to the risk and planning time involved.

New User Onboarding: Adding one user is standard support. Adding 50 users due to an acquisition is a project. The volume changes the nature of the work from a ticket to a coordinated campaign.

Structuring the Agreement

When reviewing an MSA, look for a "Definition of Services" exhibit that explicitly lists exclusions. If the contract says "includes all support," redline it. No contract includes all support.

Instead, insist on a clause that defines a "Project" by effort hours. For example: "Any single request requiring more than 4 hours of engineering time will be classified as a project and scoped separately." This provides a clear, objective trigger for billable work, removing the emotion from the conversation.

For a deeper understanding of how these definitions impact the overall cost structure of your engagement, refer to our analysis on Managed IT Pricing Models. Understanding the base fee structure is prerequisite to negotiating the exclusions effectively.

Key Takeaway

Do not rely on the term "Unlimited Support." It is a marketing term, not a legal one. Define "Maintenance" as restoration of service and "Projects" as introduction of new capabilities. This simple distinction will save hours of billing reconciliation meetings later.