In this topic I’ll share good practice on how to work with project templates in Asana. I won’t call it best practice, since I don’t claim to have that authority and you need to find out what works for you, in your context. I’m am betting that I can give you a good start though, by sharing my perspective.
CONTENT
- INTRODUCTION
– The dangers or redundant information
– Simplicity - BASICS - Basic elements of a project template
– How NOT to work with templates
– Template elements
— Project Content
— 2 Overview (Optional)
— 3 Settings - FINISHABLE PROJECT TEMPLATE - Basics
– What is this about again?
– Custom fields
– Milestones
– Test the thing! Now! - FINISHABLE PROJECT TEMPLATE - Advanced
– Dependencies
– Relative due dates
– Project Roles
– Portfolios
– Bundles - ONGOING PROCESS TEMPLATE
– Sections - MODULAR TEMPLATE
- WRAPPING UP
INTRODUCTION
Before we dive into the weeds I’d like to indicate that I feel standardisation should not be a goal in and of itself. Standardisation should serve as a baseline for continuous improvement. If you have no baseline, no clarity on how you do things, how would you go about determining what the best step forward is? It’s also not something you’d want to force top-down from an ivory tower. You want the team doing the work to be involved in creating templates.
When you’re standardising your way of work, your templates should be your source of truth.
The dangers of redundant information
Having said that, you want as few templates as possible. When you have a special template for each project variation (basic project + varying tasks), there is going to be a big incentive against changing anything in the basic project setup, because it would need to be changed in multiple templates. And if it does get updated, I am willing to bet a nice bottle of Scotch that pretty soon the basic process will not be consistent across the multiple project templates.
Simplicity
Also, Simplicity is key. It can get really tempting to want to make the template perfect. This is waste, because I’m sorry to inform you that your template will probably never be done. It should start at the smallest improvement over the current way of working, you test and improve with a small group, until it becomes the best you can come up with. That is, until someone thinks of the next improvement.
It can be difficult to make something simple though, so I will do my best to include my reasoning, and for this I need to explain the relationships the project template has to the other Asana features. Hence the length of the post.
Please don’t take the extent of my post as an incentive to apply everything. Apply the absolute minimum of what you need, and get started.
BASICS - Basic elements of a project template
Let’s start at the beginning, what is a project template? Well it’s basically a blue-print for a project. Projects can be made from this blue-print, and the project will match the blue-print that was used at the time of making the project. Like with building a house, the house doesn’t change if you change the blueprint after you’ve built the house.
How NOT to work with templates
Renaming a project to include the word “Template”. A template is not a project. It’s a different object, and something shouldn’t be considered a template if it isn’t saved as such.This is a dysfunction that leads to mistakes. (Same goes for Word and Excel templates by the way…)
The reason I call this a dysfunction is because of the risk and confusion it introduces. You can’t find your project renamed to template when you do New Project > Use Template.
Another variation on this theme is the habit of copying the latest project. This also is risky, because you can’t trust that the latest project does not have irrelevant tasks added or relevant tasks removed. And which project was the latest again? 
Template elements
We’ll go over the different elements of your template, and how to use them. You can see these elements on the left side when you’re editing your template.
1. Project content
This contains the blueprint of your project. So everything here, will be added to all new projects made from this template.
Note: This means that project membership here (right top) applies to who will be added to the new projects, and this is NOT where you manage access to the template.
A special mention for the Members access settings under Project Membership, because this setting determines what the default access is that project members will have. If the project is open to team or organisation, this is also the access level people that join themselves will have. My personal recommendation would be to set this at least set this to editor access, since this gives people freedom to multi-home tasks. Also see: # 
Multi-homing (linking work) in Asana: Examples & Best Practices
If you feel your users can’t be trusted with this access level, ask yourself what that says about the training they’ve had.
While customisation (just below Project Membership) is an option, I would advise caution against adding customisation to your template. This would make sense from a standardisation perspective. Yet I remind you that our goal is not standardisation, our goal is to set a baseline for improvement. And customisation directly in a template - assuming they are not in a bundle - will require one of two things before any change is adopted across the organisation:
- Wait until all existing projects are completed.
- Change all of the rules in all of the projects made from this template to change them.
That is a hassle you don’t want to force on anyone.
2. Overview (optional)
The text here will move to the overview tab upon creation of the project.
If you have standard information on how you work together or relevant info that you always want to include, it’s a good idea to add the list here.
For example:
Campaign number:
TEAMS link:
Important info:
3. Settings
As opposed to the project content, these settings are for the template itself.
The description of the template is the last thing someone sees before someone actually starts creating a project from this template. So it’s a good place to describe what the template is intended for, and also to add information on how one should go about filling in the next screen:
- any project naming conventions
- which team the project should be placed (defaults to team the template lives)
- which privacy setting should be used (I would advise visible to team if possible, since it prevents you having to manually provide access to new team members to all projects.)
- project due or start date (When using relative due dates, but we’ll get to that later.)
So far for the basics that apply to all project types.
FINISHABLE PROJECT TEMPLATE - Basics
The most common type of a project template is for a project. I know that sounds a bit silly when you say it like that, but hear me out. I’m not talking about project as an Asana object, but project in the sense of project management. Call it a group of work items that has an aim to be completed at some point. To distinguish it from a project in the Asana sense, I will call it a finishable project.
PS: Larry reminded me Asana uses the term deadline bound for these types of projects. To me it feels a bit odd to use this term, as you might have a fixed scope and variable deadline, or no deadline at all.
What is this about again?
To complete a finishable project the bare minimum you need is to:
- Understand the context of the project.
- Understand the desired outcome of the project.
A way to nudge people to provide clarity on this might be pre-fill the (2) Overview section with something like this:
Context:
Explain the context of the project so that someone new to the project can understand what it is about
Desired Outcome:
Describe when we should call this a project a success. This is about the why, not the how or the what. The answer to the question: “So What?”
An idea to further nudge this behaviour would be to make the first task “Setup project” and include “Define context and desired outcome on Overview tab” as a subtask. You can populate this task with any relevant steps you would require someone do when they setup the project.
As finishable projects often have a deadline, it might also be a good idea to include “Set project start and due date when applicable” as a subtask in the “Setup project” task.
Custom Fields
Custom fields can be handy, but keep your custom fields simple and to a minimum. If you’re adding custom fields to a template, you probably want to make them library fields. This is because normal custom fields would be copies with the same name. Library fields are active across the entire instance, and can be added to multiple projects. There are two reasons why this makes library fields preferable:
- Changes to a library field’s options will be active across all projects containing this field.
- Using search across projects using custom fields won’t work if the fields are copies. They need to be the same field to get all the relevant search results.
Milestones
Within your template (as with all projects) you can use tasks and milestones
Milestones are results you’re striving for. The reason you do tasks. So I’d advise to formulate the milestones as a state of things that can be celebrated. “Planning complete”, “Proposal accepted by client”, “Campaign is Live”. As it is a desired state of things, milestones cannot have a start date. And as these are the increments of value, these are also the resolution one can see when looking at multiple projects in a portfolio , either when setting Progress Type to Milestone in the List tab,
or when looking at the Timeline tab.
Tasks on the other hand should start with a verb, with a clear asks: “Review project plan”, “Arrange venue”, “Report campaign status to client”
I would encourage you to make your first template with milestones only, since the milestones are the important stuff. This will enable you to start working with your template quickly. It’s also a good way to get managers on board, since it should enable them to get a grasp of the important stuff quickly.
My last note on the basics would be to agree with your users on reasonable timeframes for project updates, since this is where you keep your stakeholders informed on how the project is going. It might be worth adding a Project setup subtask to setup reminders for project updates (either using inbuilt functionality or with recurring tasks).
Test the thing! Now!
Having implemented the above you should be more than ready to let the rubber hit the road. Let your template be used by a pilot group, and setup a feedback mechanism to ensure improvements make it to the template. Or perhaps give your pilot group edit access to the template. You would do good to have multiple trusted template editors anyway. Both to mitigate the bus factor, and to ensure minimal friction between feedback and implementation.
FINISHABLE PROJECT TEMPLATE - Advanced
As you mature your template, you will find you want to use more functionality. The things that cause the most time and frustration will be a good guide for what to start with.
Dependencies
With dependencies, you indicate a sequence in which work needs to happen, and a relationship that indicates how other work is related to your eachother. This will result in either blocking a task from happening, or being blocked by another task. Reasons you would want this include:
- You will receive a notification “Your task is no longer blocked” if someone else completes the last task that was blocking a task you are assigned to.
- If someone clicks to complete a task that is still blocked by other tasks, they will get a warning that the task is still considered to be blocked.
Relative due dates
Another option is to set due dates relative to project start or project end date. At the time of writing the functionality is as followed: You can plan project dates either after a project start date, or before a project end date. I would advise to work with weekdays, by keeping the skip weekends checkbox checked.
If you - like me - see the opportunity for improvement on this functionality your vote here would be appreciated: Relative project template dates (other than after start or before end)
It is possible to quickly setup projects with relative due dates using this workaround leveraging dependency management options 
This requires a highly skilled userbase, and most likely dedicated training to how to work with this as is far from intuitive. It’s more of a “tricking Asana into doing what you want” as opposed to “using Asana as intended”.
Depending on whether you have the plan to utilise this functionality you can add project roles, portfolios (for the new projects to be added to) and bundles.
Project roles
Assign tasks to placeholder roles, for instance: “project lead” or “visual artist”. When you create a project and assign someone to the role visual artist, all tasks that were assigned to that role will be assigned to this person.
Portfolios
When adding a portfolio for projects from this template to be added to, they will be, but not always. This requires the person using the template to have access to the portfolio in question.
Bundles
Bundles are great for ensuring consistency at scale. They allow you to connect Sections, Fields, Rules and Task Templates to a set of projects. Changing and updating the bundle will push all changes to all projects that have this bundle. By adding a bundle to the template, projects made from this template will have the Sections, Fields, Rules and Task Templates synchronised to the bundle.
ONGOING PROCESS TEMPLATE
A process is a continuous thing. Tasks arrive, go through a certain amount of steps/phases, and then are complete. For this I would advise the “board view” as the default project view.
Sections
The section setup I like to use is the following:
Inbox: Everything new
ToDo: Well defined work not started yet that is prioritised top to bottom.
In Progress: Work has started
Waiting For / blocked: Someone/something outside of the team is keeping us from completing this work.
Done: The work is done (output).
Closed: The work is confirmed to have delivered it’s desired result (outcome).
Where the tickets move left to right, it is advised to work right to left.
- First confirm if the work done has delivered the solution.
- Check if something can be done about work being blocked from progressing.
- Finish work started before starting something new
- Only then pick up the top priority next work item from the top of the ToDo section.
This system is called a kanban board.
A variation on this would be a Scrum board. The main difference in operation is the fact that Scrum works with Sprint goals: The increment of value for the customer a sprint - usually two weeks - is aimed to deliver. Milestones are perfect to use as sprint goals. For how to work with Scrum properly I refer to the Scrum Guide November 2020 version.
The basic advice on all of these is minimise the amount of work in progress.
MODULAR TEMPLATE
Chances are a lot of your projects are similar, but vary in predictable ways. Chances are there is a basic structure that always remains the same, and several modules that vary depending on what the client wants to include their project.
It would be great to have Modular Template functionality, but we don’t. Which suggests we need to duplicate project templates. 
And it would be great to be able to get a naming convention automatically applied to project names? But we can’t.
Or can we? Here is an elaborate workflow that allows for modularity in new projects AND helps maintain a naming convention by stringing together existing Asana functionality.
⚠️ Click if you're up for a challenge - Not for beginners. ⚠️
Preparation
- Create a project template that contains only what should be included in ALL projects made from this template. Well call this the base template.
- Create a project that serves as an entry point for new projects.
- Add the custom fields to this project that make up the naming convention.
- Add another custom field (multi-select) and call it
modules - Add a form to the project and ask at least the parts of the naming convention and which
modulesshould be included, and don’t forget to connect the questions to the custom fields. - Add a rule to the entry point project that utilises the
set task title to...action and changes the task title to match the naming convention using the custom fields separated by your chosen delimiter. (I use “-”) - Add rules that add the right subtasks - that will become tasks one the task is being transformed into a task - needed for the selected
modules.
Keep in mind that with Branching a rule will only execute one branch! So each module will need it’s own rule.
Putting it in action
So here is how it will work:
- Fill in form to create task.
This triggers:
- The rule that forces naming convention
- The rules add relevant sub-tasks needed for selected modules.
- Select the task and select Convert to > Project (see convert tasks into projects)
- Choose the team the project should come to live
- Click use template and find the template you want to use in the next window.
Now the following will happen:
- Task
project - Task name Project name
- Task description Added project description pre-set by template
- Subtasks Tasks in unnamed section
If you really want to make it fancy you can add automation that puts the tasks created from the modules in the right section with a couple of clicks utilising rules and custom fields in the project template, preferably in a bundle.
WRAPPING UP
Lastly, don’t forget to make it fun. And there are plenty of options to make it look good. Because people will see a lot projects made from templates.
Add some emoji’s, and put some formatting in the task descriptions. Or be creative with the board view:
Well that’s about all I can teach you about how to project templates without knowing your specific context.
I hope have found value in it.
