The Fourth Time You Build the Same Thing
The second identical warehouse is planned from memory. The third is planned from the second, badly, by whoever still has the file. What a project template actually carries across, what it deliberately does not, and the one thing you must do before trusting the programme.
A contractor who builds the same thing repeatedly — housing units, retail fit-outs, telecom sites, classroom blocks — knows the sequence completely. It is in the head of the contracts manager, and it was learned expensively, one mistake at a time, across the first four jobs.
What happens on the fifth is that somebody opens the fourth job, looks at what was done, and rebuilds a task list from it. This works, roughly, and it loses something every time: the task that was added halfway through because of a problem, the dependency somebody discovered the hard way, the checklist item that exists because an inspector once asked.
Those additions are the accumulated learning of the business, and they are exactly what does not survive being retyped by somebody who was not there when they were added.
What a template is actually for
The obvious argument is time saved, and it is the weaker one. Setting up a project takes an afternoon; the value of doing it from a template is not the afternoon.
- It preserves the corrections. Every task added because something went wrong stays in the template. Retyping loses them silently, because nobody remembers which items were original and which were scar tissue.
- It carries the dependencies. The sequence is the knowledge. Which task genuinely cannot start until another finishes is the most expensive thing a contractor learns, and it is the first thing lost when a list is rebuilt by hand.
- It makes jobs comparable. Two projects with the same task structure can be compared line for line. Two projects with similar-but-different structures cannot, and that is why most contractors cannot answer whether the third one went better than the second.
- It makes improvement cumulative. A lesson learned on site five goes into the template and appears on site six. Without one, every lesson has to be remembered by a person, and people move.
The third point is the one that changes what a business can know about itself. Consistent structure is what turns four completed jobs into a data set rather than four anecdotes.
The task somebody added halfway through because of a problem is the most valuable line in the plan, and it is the first one lost when the list is retyped.
What comes across
Cloning a project produces a new one carrying the structure and none of the history. The split is deliberate and it is worth knowing exactly where the line falls.
| Element | Carried? |
|---|---|
| Tasks, with their hierarchy of parents and subtasks | Yes — re-wired to the new copies |
| Dependencies between tasks | Yes — this is the point |
| Milestones | Yes, with their due dates cleared |
| Checklist items on each task | Yes |
| Label tags | Yes |
| Custom statuses | Yes — the workflow comes with it |
| Task dates and baselines | No — cleared |
| Assignees | No — cleared |
| Progress, completions, sprint allocation | No — cleared |
| Project code | No — codes are unique, so the new one starts blank |
The re-wiring in the first two rows is the part that matters technically. A naive copy would leave every task pointing at its original parent and its original predecessor, which produces a new project quietly entangled with the old one. Here the relationships are rebuilt between the copies, so the new project is genuinely independent.
The thing to do immediately after cloning
Every task arrives with no start date and no due date. That is correct — a template should not carry last year's calendar — and it has a consequence that will mislead you if you do not know it.
An undated task is treated as one day long by the critical path calculation. A freshly cloned project therefore has a critical path in which every activity is a single day, which produces a chain that is both very short and completely meaningless.
It does not look broken. It produces numbers, it identifies a path, and if somebody quotes a duration from it in the first week of a job they will quote something absurd with complete confidence.
Date the tasks before anyone reads the programme
This is the single most important step after cloning and it takes an hour. Work down the task list and give every activity a start and a due date, even a rough one — a wrong date produces a wrong programme you can correct, while a missing date produces a plausible programme that is wrong in a way nobody can see. Do the critical chain first if you are short of time; the float on everything else can wait.
What AWRA OpsHub does today
- Tasks with their full hierarchy, re-wired so parents and subtasks point at the new copies rather than the original.
- Dependencies between tasks, rebuilt between the copies — the sequence is the thing worth keeping and it survives.
- Milestones, checklists, label tags and custom statuses, so the workflow arrives with the structure.
- A clean slate on history — dates, baselines, assignees, completions and sprint allocation all cleared, so a new job does not inherit last year's progress.
- Save-as-template as well as instantiate, so a job that went well can become the blueprint for the next one.
What it does not do
- No relative date offsets. A template cannot say "this task starts on day fourteen"; every task comes back undated and has to be scheduled by hand. Until they are dated, the critical path treats each as one day and produces a chain that means nothing.
- No materials, bill of quantities or budget lines on the template. The structure of work is carried; the quantities and rates behind it are not.
- No template versioning. Improving a template does not update or notify projects already created from it, and there is no record of which version a job was built from.
- No role placeholders. Assignees are cleared rather than carried as roles, so "site agent" cannot be a slot on the template that you fill per job.
Not ours, by choice
- We will not carry dates into a new project. A template that arrives pre-scheduled looks helpful and produces a programme somebody accepted without reading, which is worse than a blank one that has to be filled in deliberately.
- We will not link a project back to the template it came from in a way that lets a later edit propagate. A live job whose plan can change because somebody edited a blueprint elsewhere is not a plan anybody can rely on.
Relative date offsets on template tasks, role placeholders instead of cleared assignees, and template versioning with a record of which version a job was built from, are all scope rather than ceilings. The clone service, the dependency re-wiring and the custom-field system all exist and work; each is a written specification and a price.
The undated-task consequence is the practical one. It is not a defect in cloning — clearing dates is right — but it interacts with how the critical path handles missing dates, and the combination will hand you a confident wrong answer in the first week of a job if nobody has been told.
Building a template worth using
The usual approach is to design one carefully in advance, which produces a template reflecting how somebody thinks the work goes. The better approach is to take a job that actually went well and save it.
-
Start from a real completed job, not a blank page
It already contains the tasks that were added when things went wrong, which are the ones you most want to keep. A template designed from first principles contains only what somebody remembered to include.
-
Strip the genuinely site-specific work
Whatever existed because of that particular ground, that particular client or that particular access constraint. Be conservative — a task that is occasionally irrelevant is cheap to delete, while a missing one costs you the thing the template was for.
-
Check the dependencies are real
This is where to spend the time. Every arrow should represent a genuine physical or contractual constraint. Arrows drawn to make a diagram look complete produce float that does not exist, and that is the error that matters.
-
Put the checklists in
Checklist items travel with the tasks, and they are where site-specific knowledge lives most durably — the inspection somebody has to be present for, the certificate needed before the next trade starts, the thing that goes wrong if it is done in the wrong order.
-
Name it for the type of job, not the client
Two-storey retail fit-out, not "the Karen job". A template named after a client is used by people who worked on that client and ignored by everybody else.
-
Improve it after every job
Half an hour at handover, while what went wrong is still fresh. Since a template does not version and does not propagate, this is where improvement compounds — and it is a habit rather than a feature.
The last one is what determines whether templates are worth anything in two years. There is no mechanism to remind you, and there is no record of which version a job was built from, so a half hour at handover is the entire improvement loop.
What consistent structure lets you ask
Once several jobs share a task structure, a class of question becomes answerable that was not before, and these are usually the questions a contractor most wants answered.
Questions that need comparable jobs
- Which activity overruns most often across our last six jobs of this type?
- How long does this stage actually take, as against how long we price it at?
- Which task is on the critical path every single time, and have we ever tried to shorten it?
- Where do we consistently lose float, and does it happen early or late in the job?
- Which tasks does nobody ever complete, meaning they should not be in the template at all?
None of these can be asked about four jobs with four different task structures, which is the position most contractors are in without ever having decided to be. The templates are not really about the afternoon they save at setup — they are about being able to ask the first question on that list.
The scheduling arithmetic these structures feed is in the chain that decides your finish date, the cost comparison in BQ versus actuals, and the recurring-work discipline in the inspection that stopped recurring.
Our take
Build your template from a job that went well rather than from a blank page, because the tasks added mid-job when something went wrong are the ones worth keeping and the ones a fresh design always misses. Then date every task before anybody reads the programme — cloning clears dates deliberately, and the critical path treats an undated task as one day, so a fresh clone will hand you a short, confident and entirely meaningless chain. And spend half an hour improving the template at every handover, because there is no versioning and no propagation: that habit is the whole improvement loop.
See a project built from a template
Tasks and their hierarchy re-wired to the new copies, dependencies preserved, milestones, checklists and custom statuses carried, and a clean slate on dates, assignees and progress.
Explore project templatesFrequently asked questions
What does cloning a project carry across?
The structure: every task with its hierarchy of parents and subtasks, the dependencies between them, milestones, checklist items, label tags and custom statuses. The relationships are rebuilt between the new copies rather than left pointing at the originals, so the new project is genuinely independent. What it does not carry is history — dates, baselines, assignees, completions and sprint allocation are all cleared, so a new job does not inherit last year's progress.
Why do all the tasks come back with no dates?
Because a template should not carry last year's calendar, and a pre-scheduled plan is one somebody accepts without reading. The consequence is worth knowing though: the critical path treats a task with no dates as one day long, so a freshly cloned project produces a chain in which every activity is a single day. It does not look broken — it returns numbers and identifies a path — so date the tasks before anybody quotes a duration from it.
Can a template say a task starts on day fourteen?
No. There are no relative date offsets, so every task arrives undated and has to be scheduled by hand on each new job. For a contractor building the same thing repeatedly that is real repeated work, and it is worth scoping deliberately if it is the difference between using templates and not. In the meantime, date the critical chain first — the float on everything else can wait a week.
If we improve a template, do existing projects update?
No, and that is deliberate. A live job whose plan could change because somebody edited a blueprint elsewhere is not a plan anyone can rely on. The cost is that there is no versioning and no record of which version of a template a job was built from, so improvement is entirely a habit: half an hour at handover while what went wrong is still fresh. Nothing will remind you, and that half hour is the whole improvement loop.
Should we design a template or save an existing job as one?
Save a real job that went well. It already contains the tasks somebody added halfway through because a problem appeared, which is exactly the accumulated learning you want to keep — and it is precisely what a template designed from first principles always lacks, because nobody remembers to include the corrections. Then strip the genuinely site-specific work, and be conservative about it: a task that is occasionally irrelevant costs a moment to delete, while a missing one costs you the thing the template was for.
What is the real benefit of using templates?
Not the setup time. It is that jobs with the same task structure can be compared line for line, which turns four completed projects into a data set rather than four anecdotes. Once that holds you can ask which activity overruns most often, how long a stage actually takes against how you price it, and which task sits on the critical path every single time. Those questions cannot be asked about four jobs with four different structures, which is where most contractors are without ever having chosen to be.
