“Light projects included” can be a useful idea for SMEs: it suggests ongoing improvements won’t always be treated as separate, disruptive work. The risk is that “projects” becomes an undefined bucket. That creates scope ambiguity, approval bottlenecks, and decision latency—exactly the friction a managed relationship is meant to reduce. This article is for owners and Ops leads who want to understand what “projects included” should mean operationally, without drifting into delivery playbooks or tool choices. The focus is governance: clear boundaries, decision rights, change control expectations, and transparency so improvements protect (not erode) baseline consistency.
What “light projects included” is trying to solve (operationally)
Change demand in small businesses (concept level)
Small businesses change constantly: new starters, new suppliers, new systems, new workflows, compliance requests, and customer demands. If all change is treated as “extra”, it often gets deferred until risk or pain forces action.
The difference between reactive support and planned change
Reactive support restores service. Planned change improves how the business operates. Including some change capacity can reduce firefighting—but only if governance clarifies what work enters the pipeline and how it is prioritised.
The core risk: undefined “project” boundaries
Scope ambiguity and delayed decisions
If “project” is undefined, every request becomes a negotiation: is it BAU support, an improvement, or a separate engagement? That ambiguity creates delays and undermines trust.
Ownership and approval bottlenecks
Change work requires business decisions: priorities, acceptable disruption, budget where relevant, and timing. If decision rights are unclear, approvals stall. The provider cannot progress, and the business experiences it as “nothing moves”.
Governance needed when change is included
Intake and prioritisation (concept level)
Change needs a simple intake and prioritisation method: what the request is, why it matters, who approves it, and where it sits relative to other work. This is governance cadence in practice.
Change control and documentation expectations (concept level)
Change control does not require heavy process, but it does require clarity: what changed, who approved it, and how it will be supported going forward. Documentation is about continuity and accountability, not bureaucracy. Buyer governance norms in the Model Services Contract and NCSC MSP due diligence both point to defining change control and decision rights upfront.
Reporting cadence and transparency
A managed relationship should make change visible: what is in the queue, what was completed, what is blocked on business decisions, and what risks are being deferred. Transparency reduces friction and prevents surprise.
Baseline consistency through change
Ensuring changes don’t erode agreed baselines (concept level)
Changes should not quietly introduce scope drift, unmanaged access, or inconsistent practices. Baseline consistency means that improvements are aligned to the same operational rules: defined ownership, controlled access, clear exceptions, and evidence that survives change.
Questions to ask before accepting “light projects included”
What counts, what doesn’t, and who decides
Define the boundaries: what qualifies as “light”, what is excluded, what triggers a separate change conversation, and who makes the final call. Without this, “included” becomes subjective.
Dependencies, third parties, and approvals
Many changes depend on third parties (software vendors, telecoms, cloud providers) or business approvals. Define how dependencies are handled, what access is needed, and what happens when external delays occur.
Common misconceptions
“Projects included” means unlimited change on demand. Included change capacity still needs prioritisation and boundaries.
Change work can be treated separately from governance and security baselines. Change is where baselines are most likely to drift unless governance is explicit.
Lack of definition increases flexibility (it typically increases friction and decision latency). In practice, it increases friction and decision latency.
Documentation is optional for small changes (it affects accountability and continuity). Even small changes affect continuity, ownership, and future troubleshooting.
What to do next
Define BAU support vs change work in plain English.
Establish decision rights: who approves, who prioritises, and what “urgent” means for change.
Agree on change visibility: a simple queue and reporting cadence.
Set minimum change records (what changed, who approved, ownership going forward).
Make third-party dependency handling explicit to avoid hidden delays.
