Control scope creep in IT projects by comparing each new request with the signed scope before assigning the work. When a request changes the agreement, the project lead records the additional work and its price, then obtains the client's approval before scheduling it. The engineer needs an approved task, not a promise that someone will sort out billing later.
I'd keep the change order to a page where the detail allows it. The useful limit is whether the client can understand what they're approving. A complicated dependency still needs explaining, even if it spoils the page count.
Check the Agreement Before Calling It Extra
A change order records an agreed alteration to an existing project. Start with the accepted quote and the assumptions attached to it. A request is additional scope only where that agreement supports the distinction.
Say a client asks the engineer to include another site in a network project. If the quote lists the included site and excludes work elsewhere, the project lead can explain the difference. If the quote promises an undefined company-wide rollout, the same request exposes a scoping problem that needs resolving with the client.
Don't treat an extra hour as proof of extra scope. Your estimate may have been wrong, or the team may be correcting its own work. Those possibilities belong in the project review before anyone presents the client with a bill.
Give Each Request an Owner
The engineer records the request on the project and sends it to the project lead. The lead checks the scope and estimates the effect on delivery. The person authorized to approve spending for the client then decides whether the change proceeds.
Keep affected work visibly awaiting that decision. Continue unrelated approved tasks where the dependencies allow it. If the request blocks the remaining project, explain the scheduling effect instead of letting the engineer choose between unpaid work and an unexplained delay.
- The engineer records what was requested and where it differs from the assigned task.
- The project lead checks the agreement, estimates the change, and sends the proposed order to the client's authorized approver.
- The scheduler updates the work plan after approval and confirms which existing commitments move.
- The billing owner receives the approved order with the project reference and agreed billing treatment.
My view is that goodwill work needs the same visibility. The owner can choose to include an extra task, but the project should still show its estimated effort and who approved absorbing it. Otherwise the next engineer has no way to tell a deliberate concession from an omission.
Put the Decision on the Page
The change order should let the client compare the new request with the original promise. Keep the reason specific enough that the engineer and billing owner can use the same record. These fields make that possible:
- Identify the project, the original quote, and the change-order reference.
- Record the client's request in their words and the date it was received.
- Explain why the request changes the agreed scope, citing the relevant inclusion, exclusion, or assumption.
- Describe the additional deliverable and what remains excluded.
- State estimated hours, the pricing basis, and the additional price. Identify any equipment or license charges separately.
- Explain the effect on milestones and any dependencies the client must resolve.
- Record the authorized client's approval and the approval date, with work scheduled after that approval.
If a changed condition affects an assumption in the quote, explain both parts. Name the condition you found and the work it now requires. That is more useful than a line reading unforeseen circumstances, followed by a total.
Price the Work Before It Reaches the Board
The US MSP model uses a blended project rate of $185 an hour and targets a 50% project gross margin. For labor priced by the estimate, multiply the additional hours you have actually scoped by that rate. Keep the estimate attached so a revised task can be repriced without guessing where the original number came from.
The model's project engineer has an $84,000 salary. At the general US burden multiplier of 1.25, that becomes $105,000 in annual burdened pay. Project capacity is then assessed against 1,660 available annual hours at 85% project utilization, rather than assuming every paid hour can be sold.
Those inputs explain why the quoted rate cannot be compared with salary alone. They don't prove that an individual change will achieve the target margin. Check its actual delivery cost and any other costs the agreed scope requires before approving the price.
The model's US example has $290,769 of annual project revenue and $155,908 of project labor in its stable setting. Its unpaid new-client onboarding is included in that labor. Keep that classification visible when reviewing results, because a change-order process cannot make unpaid onboarding become billed project work.
Tell the Client What Happens Next
I'd make the message short: describe the requested addition, point to the agreed boundary, and explain what approval would change. State the price and the scheduling effect together. A client deciding whether to add work needs both.
Treat a question about the price as a question to resolve, not permission to start. If the client chooses a smaller addition, revise the deliverable and estimate before approval. Keep the original scope identifiable so the engineer isn't reconstructing the decision from a message chain.
An urgent request still needs a clear decision about authority and cost. Establish how your team obtains approval under the client's agreement, and record the decision with the work. Calling a request urgent doesn't tell the billing owner who agreed to pay for it.
Find Out What the Overrun Actually Means
At completion, compare actual hours with the original estimate plus approved changes. Investigate the difference by task. An hours gap can reflect estimation error or rework as well as unapproved additions, so don't label the whole gap scope creep.
Review project revenue against project labor on a consistent basis. A weak result can also reflect utilization, unpaid onboarding, or a mismatch between the quoted rate and the cost of the people assigned. Use the project records to distinguish those explanations before changing the approval process.
For the next additional request, give the project lead the signed scope and ask for the completed change order before the scheduler adds the task. Check that the same approval reaches billing. That handoff is where an agreed price becomes something your MSP can actually invoice.
mspoutpost.com/articles/scope-creep-in-it-projects-approve-changes-before-work
Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.