A Recurring Task or a Project? Give Ongoing Work and a Bounded Change Different Plans

“Keep the shared resource list accurate” and “replace the shared resource list with a better system” can appear next to each other on a task board. They concern the same subject, but they need different plans. The first continues as long as people rely on the list. The second should produce a defined change and reach a point at which the project can close.

Treating both as a single permanent project can hide ordinary maintenance. Treating both as routine tasks can hide the coordination needed to make the change. The useful distinction is what completion means and what work must continue afterward.

Look for a finish condition before choosing the label

The Association for Project Management describes a project as a temporary endeavor directed toward planned objectives, distinct from ordinary ongoing activity. For a small team, that does not require elaborate software or a formal project office. It suggests a practical question: what observable outcome would let us say this particular change is complete?

“Improve the resource list” is vague. “Create an agreed list, verify the entries, put it where staff can access it, and assign its maintenance” describes a bounded result. “Review new entries each week” describes recurring operation. Both may be necessary, but one does not disappear when the other begins.

A task's frequency alone does not settle the distinction. A yearly event can be managed as a project because each occurrence needs a defined result, preparation, and closure. A daily problem can require a project if the team is changing the underlying process. The question is the work's structure, not whether it happens often.

Follow one example from change to ordinary use

Imagine a small organization with a shared list of meeting equipment. Staff regularly correct availability and location information. They also want to replace an confusing spreadsheet with a clearer request process. This is a fictional planning example, not a claim that a particular organization tested a method.

First, preserve the ongoing job. Someone must still answer equipment requests and keep availability current while the replacement is being developed. Allocating the same person's full week to the change does not make that continuing demand disappear. If the team cannot cover both, it needs to adjust scope, timing, or responsibility.

Second, describe the bounded change. The team might agree that the new process must allow a requester to identify an item, obtain a confirmed response, and know what to do when plans change. The team can then test that route with ordinary examples before retiring the old one. “New form published” is a narrower result than “requests can be completed.”

Third, define the handoff. Who updates the equipment information? Who resolves a request that cannot be fulfilled? Where do staff report a confusing instruction? If the project ends without these answers, its unfinished operational responsibilities will return as interruptions to whoever built it.

Finally, choose an end point for the project itself. It might include accepted work, documentation, transferred access, and an agreed period for resolving launch issues. That is a team decision appropriate to the task, not a universal duration. The ongoing service remains after the change project closes.

Compare the planning questions

The table is a comparison aid. Some work contains both columns, and that is often a reason to split the plan rather than debate a single label. A team can keep a recurring checklist while tracking the change separately.

Our guide to one owner or a rotating coordinator helps distinguish accountability from day-to-day coverage. Rotation may make the recurring job sustainable, while one person remains responsible for the change's outcome. Those arrangements can coexist if the boundaries are clear.

Do not use the project label to hide an indefinite obligation

A project named “Maintain the equipment list” may stay open forever. That can make progress reporting unhelpful: the team repeatedly appears not to finish, even though it completes useful work each week. Move the continuing obligation into ordinary operations and identify any specific improvement as a separate piece of work.

The reverse problem appears when a recurring task quietly grows into a redesign. “Update the list” now involves interviewing users, choosing a different structure, migrating information, and teaching staff. The old time allowance no longer describes the work. Renaming the task is less important than making the new scope and dependencies visible.

One way to spot this change is to ask whether the next occurrence resembles the previous one. If each update uses a known process and has familiar exceptions, a recurring instruction may fit. If the team must discover requirements, coordinate new decisions, and change other people's work, it needs a plan for that uncertainty.

For documentation, choose between a checklist and a full procedure according to who will do the recurring work. A project's background notes can help explain how a process was built, but they may be an awkward substitute for the instructions someone needs during an ordinary request.

Give improvement a place after the project closes

Closing a project does not mean a service should never change again. GOV.UK's service lifecycle guidance treats maintenance and continuing improvement as work that needs people and resources throughout a service's life. The same planning distinction is useful on a smaller scale: decide who notices problems, who prioritizes changes, and where that work is recorded.

An operational owner does not have to implement every suggestion immediately. They need a way to distinguish an ordinary correction, a broken process that needs attention, and a proposed improvement that can be considered later. Without that distinction, every request can feel like either an emergency or an ignored idea.

If a tool is being proposed as the answer, first examine the handoff the tool would support. A replacement application cannot determine who maintains the list or what counts as a completed request. Those responsibilities survive a change of software.

Watch for seasonal work and repeated projects

Some work repeats without becoming a single continuous task. Consider preparing a yearly staff conference. The organization may reuse a checklist, but each conference has its own date, venue, speakers, and finish. Treating each occurrence as a bounded project can make sense, while maintaining the reusable checklist remains an ongoing responsibility. Repetition and temporary scope are not opposites.

Now compare an equipment inventory checked every month. If each check follows an established method, it may fit ordinary operations. If the organization decides to reconcile years of inconsistent records across locations, that cleanup may be a separate project. Once the cleanup is accepted, the monthly checks still need to continue. A project can repair the starting position without replacing maintenance.

This distinction helps with estimates. The time needed for one routine check is not necessarily a useful estimate for a one-time reconciliation. The reconciliation may involve discovering missing records, resolving competing accounts, and deciding who can authorize corrections. A familiar noun, such as “inventory,” can conceal a different kind of work.

Keep the reusable parts after a project closes: a tested checklist, current contacts, an explanation of unusual decisions, and a record of what changed. Do not carry every old task forward as unfinished work. The next occurrence should inherit useful knowledge while getting its own current scope and assumptions. That makes repetition easier without pretending that every year's event or every location's cleanup is identical.

Write two small commitments

Try writing an ongoing commitment and a change commitment side by side. For the equipment example, the first might be: “The duty coordinator keeps current requests moving and hands over unresolved cases.” The second might be: “The project owner delivers the agreed replacement process and transfers maintenance to the service owner.”

Then check that the same hours have not been promised twice. Identify who covers the existing service during project work, how interruptions affect the schedule, and who can change priorities. A clear distinction between recurring work and a project is useful because it makes these commitments visible, not because one label is more impressive than the other.