Maintenance work vs. project work: make room for both

Plan maintenance work and project work together, but give them different completion rules. A project ends when an agreed outcome is delivered. Maintenance continues as long as something needs care. Keep a visible list for each, reserve time for both, and decide explicitly what moves when an unexpected request cannot fit.

What is the difference between maintenance and a project?

The Association for Project Management distinguishes projects from ongoing management by their finite timespan and final deliverable. That distinction is useful even when you work alone: launching a client's new site has an end, while checking and maintaining it creates continuing obligations.

Planning projects and maintenance

Project work	Maintenance work
Finish: an accepted outcome, such as a published brochure	Finish: each check or repair ends; the service continues
List: steps needed for the agreed deliverable	List: scheduled checks and incoming service requests
Protect: time before a delivery commitment	Protect: enough capacity to meet the agreed service needs

Size alone does not decide the category. Replacing an entire site may need its own scoped project even if the request first arrives in a maintenance conversation. A five-minute correction can stay a maintenance task when it falls within the existing service agreement.

Keep two lists and one weekly budget

Keep finite deliverables in their own projects. Put routine checks and small service requests in a clearly named maintenance list for the relevant client or business function. Give each entry a concrete action and record the requester, expected effort, and any agreed response or completion requirement.

Then plan from one total amount of available time. Subtract leave and business administration before dividing the remaining hours between delivery, known maintenance, and uncertainty. The freelance capacity worksheet helps establish that total; this guide addresses how to allocate the work you already support.

Review recent maintenance demand before setting the allowance. A quiet week is weak evidence for a permanent reduction. If routine requests consume the entire buffer repeatedly, increase the explicit maintenance allocation or change what you promise. Calling predictable work an emergency does not create more time.

Worked example: a four-hour request arrives midweek

Imagine a freelance designer has 24 hours available after administration and personal commitments. This is a hypothetical allocation, not a recommended working week:

• Project delivery: 15 hours. Nine for a website draft and six for a brochure.
• Known maintenance: 5 hours. Three for content changes and two for a flexible audit.
• Unallocated contingency: 4 hours. Held for work that cannot yet be named.

The total is 15 + 5 + 4 = 24. On Wednesday, the client reports a broken contact form. After checking the impact and scope, the designer estimates four hours to repair and verify it.

Suppose the two-hour audit has not begun, has no fixed deadline this week, and the client agrees to move it. Replacing that audit with the repair raises this week's maintenance from five hours to seven: 5 − 2 + 4 = 7. Two contingency hours cover the increase. The revised plan is 15 + 7 + 2 = 24.

The audit still exists. Put it into a later week only after checking that week's capacity. If the audit cannot move, the repair uses all four contingency hours instead: 15 + 9 = 24. There is then no buffer left. A further request requires another scheduling decision, rather than an invisible extension of the working day.

Use a short intake check before interrupting delivery

1. Identify the impact. What is failing, who is affected, and what happens if it waits? Ask for enough detail to distinguish a service problem from an enhancement.
2. Check the agreement. A promised response time may differ from a promised resolution time. Use the actual commitment when planning the next action.
3. Estimate the next useful step. When the repair is unclear, schedule a bounded investigation before promising a completion date.
4. Name the capacity source. Use available maintenance time, contingency, or an explicitly moved task. Check dependencies before shifting project work.
5. Confirm the effect. Tell the affected client if scope or timing changes. Record the revised plan and the work you deferred.

Use the task triage guide when several requests compete. Keep enhancements that need a new estimate out of the accepted maintenance queue until their scope is agreed.

Keep the distinction visible in ProjectBook

Use projects and their tasks to organize the work. A project named “Client website maintenance” can hold continuing service tasks, while “Client website redesign” holds the finite deliverable. These names express your planning convention; they do not create different product modes.

Record estimated duration on the task and schedule the work in the planner. Keep the weekly allocation in the project description or a separate worksheet, and update it manually when priorities change. ProjectBook does not need to calculate capacity automatically for this method to be useful.

At the next review, compare completed maintenance with the allowance and inspect anything deferred. Browse the project management guides for the next step: setting a realistic delivery date once both kinds of work are accounted for.