The Project You Run Twelve Times a Year
Some work is genuinely new. Most is not. The quarterly audit, the tenant fit-out, the school term rollout, the monthly compliance return — the same fourteen steps, in the same order, rebuilt from memory every time by whoever happens to be free.
Ask a Kenyan services firm how they run a recurring engagement and the honest answer is usually a WhatsApp message that says "do it like the last one". Somebody opens the previous job, reads down the task list, retypes what still applies, and forgets the two steps that only came up once and turned out to be the two that mattered. The knowledge is real. It just lives in a person rather than in the business.
Two features address this, and they solve genuinely different problems. Templates handle the shape of a job you run repeatedly. Recurring tasks handle a single obligation that comes round on a clock. Confusing them is the most common reason people conclude neither works.
The two problems, and which tool fits
What kind of repetition are you actually dealing with?
File the monthly return
One task, monthly, forever. A recurring task. Making a project out of this is overhead with no payoff.
Weekly site safety walk
One task with a short checklist, every week. Recurring task, with the checklist attached to it.
Quarterly internal audit
Twelve to twenty tasks, dependencies between them, a milestone at sign-off. A template, instantiated four times a year.
New tenant fit-out
A full project shape with different dates, budget and people every time, but the same skeleton. A template, every time.
Onboarding a new client
Usually a template. It looks small until you list it out and find eleven steps, three of which involve someone outside your team.
The dividing line is not size — it is whether the work has internal structure. If step four cannot start until step two finishes, you want a template. If it is one thing that just needs doing again, you want recurrence.
Templates: what carries over and what deliberately does not
A template is just a project marked as a blueprint. It is hidden from your active project list so it never pollutes your dashboards, and it lives in its own templates area. Instantiating it copies the structure into a new working project. Saving any existing project as a template goes the other way — you finish a job that went well, and turn it into the way you do that job from now on.
What matters is knowing exactly which fields survive the copy, because a wrong assumption here produces a plan that looks right and is scheduled in the past.
Cloning a project: what comes across
| Carried into the new project? | Copied |
|---|---|
| Every task, including subtasks with their parent relationship intact | Yes |
| Dependencies between tasks, remapped onto the new copies | Yes |
| Milestones, and each task's link to its milestone | Yes |
| Checklist items on each task — reset to not done | Yes |
| Labels on tasks | Yes |
| Custom per-project statuses and board columns | Yes |
| Task descriptions, priorities, story points and estimates | Yes |
| The project's own start and due dates, budget, cost and bill rates, customer, owner and department | Yes |
| Task start dates, due dates and baselines — cleared, so the new plan is scheduled fresh | No |
| Milestone due dates — cleared, and milestones reset to open | No |
| Task assignees — cleared, so nobody inherits work they have not been given | No |
| Completion state — every task starts open | No |
| Sprint membership — tasks come across unassigned to any sprint | No |
| The project code, which must be unique — left blank for you to set | No |
| Comments, attachments and logged time | No |
| Recurrence links on tasks — a copy is a fresh series, not a continuation | No |
Built and maintained Configurable by you, not maintained by us Not built
The row worth reading twice is the eighth: the project's own dates, budget and rates carry over, even though every task date is cleared. So a template made from a job that ran in March will hand you a new project still dated March. Set the project dates immediately after instantiating — it is one field and it is the single most common oversight.
Why assignees are deliberately dropped
It is tempting to want the same people pre-assigned. We clear them on purpose. A cloned plan with stale assignees sends notifications to people who have not agreed to the work, and — worse — makes a task look owned when nobody has actually picked it up. An unassigned task is honest about needing a decision. A wrongly assigned one is not.
Recurring tasks: how the clock actually works
A task can carry a recurrence — daily, weekly or monthly — with an interval, so "every two weeks" and "every third month" both work, and an optional end date after which the series stops.
Here is the part that decides whether recurrence helps you or quietly fails: the next occurrence appears when you complete the current one. It is not generated on a calendar in advance. Completing the task spawns its successor with the dates shifted forward by one interval, preserving the original duration. A daily background pass at 07:35 catches any completed recurring task whose successor was somehow never created, so nothing is permanently lost — but it too only looks at completed tasks.
The consequence is direct and worth stating plainly: if nobody ever ticks the task off, the next one never appears. Recurrence rewards closing work. It does not compensate for not closing it.
Five rules for recurrence that actually holds
- Set dates deliberately. Dates are what recurrence shifts forward, and what the end date is measured against. A task with no dates at all still recurs — the next occurrence gets a due date seeded from today plus the interval — but you have handed the schedule to whenever somebody happened to tick the last one off.
- Set the end date if the obligation ends. A statutory return that stops when a contract ends should stop in the system too, rather than generating occurrences into next decade.
- Attach the checklist to the recurring task, not to a document. Checklist items are copied to each new occurrence and reset to not done, which is exactly the behaviour you want for a repeated procedure.
- Keep the task the unit of recurrence, not the project. If your monthly obligation is really eight steps, that is a template you instantiate monthly, not one recurring task with a long description.
- Complete the task when the work is done, not when you remember. The clock starts from completion, so late ticking pushes the whole series later.
Building a template that is worth having
-
Start from a real job, not a blank page
Take a project you have actually finished — ideally one that went well and one that went badly, so you capture the steps that were added under pressure. Save it as a template. A template written from imagination is missing precisely the steps experience adds.
-
Strip out what was specific to that client
Names, negotiated amounts, one-off concessions. The template should contain the shape of the work and the knowledge, not the details of one engagement.
-
Add the steps everyone forgets
The handover email. The certificate that takes three weeks. The deposit that must be requested before mobilisation. These are exactly the tasks that never survive "do it like the last one" — and they are the reason a template pays for itself.
-
Wire the dependencies
Dependencies are copied, so encoding them once is permanent. Do not encode dates; encode order. Dates belong to the instance, order belongs to the method — which is why dependencies and the critical path is the companion piece to this one.
-
Put the acceptance criteria in checklist items
A task called "Test the installation" tells nobody anything. Four checklist items under it tell the next person exactly what "tested" means, and they reset clean on every instantiation.
-
Improve it every time you use it
The habit that separates a live template from a dead one: when something goes wrong on an instance, add the missing step to the template the same week. A template nobody edits becomes a template nobody trusts within about three cycles.
What we do and do not do
What AWRA OpsHub does today
- Any project markable as a template, hidden from active project lists and listed in its own templates area.
- Instantiating a template into a new working project, or saving an existing project as a template.
- Tasks, subtask hierarchy, dependencies, milestones, labels, checklist items and custom statuses all copied.
- Dates, assignees, completion state and sprint membership cleared on the copy, so the new plan is scheduled deliberately.
- Checklist items reset to not done on every copy.
- Recurring tasks — daily, weekly or monthly with an interval and an optional end date.
- The next occurrence spawned on completion, with dates shifted by the interval and duration preserved.
- A daily catch-up pass so a completed recurring task whose successor was missed still gets one.
- A series link back to the originating task, so occurrences stay grouped rather than looking unrelated.
- An end date that reliably stops the series — including on an undated task, whose next due date is seeded from today so there is something for the end date to be measured against.
What it does not do
- Clearing the project's own start and due dates on a clone — task dates are cleared, project dates carry over and must be reset manually.
- Generating future occurrences in advance, so you cannot see next quarter's recurring tasks on a calendar today.
- Recurrence on a whole project — only individual tasks recur; a repeating project is a template you instantiate.
- Recurrence rules beyond daily, weekly and monthly with an interval: no "last working day of the month", no "every second Tuesday", no skipping public holidays.
- Copying comments, attachments or logged time onto a cloned project.
- Templates with variables or prompts — no "ask for the client name and substitute it into eight task titles".
The two worth knowing before you rely on this: the project dates carrying over on a clone, and recurrence being completion-driven rather than calendar-driven. Neither is a defect you will hit by accident once you know about them — which is why they are stated here rather than buried.
Our take
Templates are the cheapest institutional memory a services business can buy, and the only feature in the project module where the return is immediate and obvious — you save an hour of retyping and, far more valuably, you stop losing the three steps that only the person who left knew about. Recurrence is narrower than most people expect and that is fine: use it for single obligations on a clock, use templates for anything with structure, and set dates on both.
How the plan itself should be shaped is in subtasks, milestones and statuses, what it costs you is in project budget vs actual, and what to carry forward from a finished job is in closing a project.
Stop rebuilding the same plan
Save a job that went well as a template, instantiate it with the dates and people of the day, and keep the steps everybody forgets in the one place that never forgets them.
See project templates in AWRAFrequently asked questions
What is the difference between a template and a recurring task?
A template is a whole project shape — tasks, dependencies, milestones, checklists — that you instantiate whenever you run that kind of job. A recurring task is one task that reappears on a clock after you complete it. Use a template when the work has internal structure, meaning some steps depend on others. Use recurrence when it is a single obligation that simply needs doing again. Trying to force a multi-step process into one recurring task is the usual reason people find recurrence disappointing.
When I instantiate a template, what dates does the new project have?
Every **task** date is cleared, including baselines, so the plan is scheduled fresh. But the **project's** own start and due dates are copied from the source, along with its budget, cost and bill rates, customer, owner and department. So a template built from a job that ran in March hands you a new project still dated March. Reset the project dates immediately after instantiating — it is the most common oversight and it takes ten seconds.
Are people pre-assigned when I copy a project?
No, deliberately. Assignees are cleared on the copy. A cloned plan with stale assignees notifies people who never agreed to the work and makes tasks look owned when nobody has picked them up. An unassigned task honestly signals that a decision is needed; a wrongly assigned one hides it.
Do I see next month's recurring tasks in advance?
No. Occurrences are not generated ahead of time — the next one is created when you complete the current one, with the dates shifted by the interval. A daily background pass catches any completed recurring task whose successor was missed, so nothing is permanently lost, but it also only looks at completed tasks. The practical implication: if nobody ticks the task off, the next one never appears, and your forward calendar shows one occurrence rather than a series.
Can a whole project recur monthly?
Not as a recurrence rule. Only individual tasks carry recurrence. A repeating project is handled as a template you instantiate each cycle, which is arguably better anyway — each instance gets its own dates, budget and people, and you can improve the template between runs without disturbing the ones already running.
What recurrence patterns are supported?
Daily, weekly and monthly, each with an interval, so "every three days", "every two weeks" and "every quarter" all work, plus an optional end date. What is not supported is anything cleverer: no "last working day of the month", no "every second Tuesday", and no skipping public holidays. If your obligation genuinely falls on the last working day, set it monthly and accept a manual nudge, or tell us — the pattern set is a contained thing to extend.
Do checklists come across, and do they reset?
Yes to both. Checklist items are copied onto every clone and onto every new recurring occurrence, and they are reset to not done. That makes checklists the right place to put acceptance criteria for repeated work — the procedure is captured once and starts clean every time it is run.
