How We Use Tasks

Our current default PM tool is Asana. See
Asana Tasks
for information about how this workflow maps into Asana specifically.

What is a Task?

A task is either a...

  • Problem to be solved: This is a specific issue that we are trying to address through our work. For example: “Homepage bounce rate is too high”
  • Outcome to be achieved: This is something additive that we want to accomplish or implement, which is better described in the positive. For example: “Craft license key is purchased and implemented in the CMS”

The task title in a software tool should generally reflect one of these formats.

The strategist’s job is to translate client requests/project needs into one of these formats, and present it to the team with its associated constraints and information. They can choose the format that is most natural for the work to be done. Bugs and issues typically are best stated as problems, whereas additive work is best phrased as an outcome.


Tasks should stay assigned to one person (usually a designer or developer) for the lifecycle of the task instead of moving from person to person. The one person is principally responsible for Cantilever getting the work done. They are responsible for requesting required Strategic, Peer Review, and QA approvals.

When tasks are clarified by strategists the strategist should specify which approvals the assignee should seek when they have satisfied the “Definition of Done”

Example: If Roman takes on a new task for BPC, Roman will stay assigned to that task in Asana until it is deployed. During the Approval and QA process, other people will be assigned sub-tasks for those approvals, but the main task will stay on Roman.

This means that in order to work effectively at Cantilever you will also want a solid personal task management of your own. This can be your own Asana list/projects, pen & paper (Try the Bullet Journal by our friend Ryder Carroll), TextEdit, OS X Reminders, Remember the Milk, Google Tasks, Todoist, OmniFocus, Things, etc. Don‘t use your memory for this.

Task Lifecycle

Most tasks start with some sort of client request – either in the context of a larger project, or individually. For example, if we support a website, the client may ask for us to update WordPress. The task lifecycle might look like:

  • Clarification: The Strategist should evaluate the request and understand it fully. Why does the client want to update WordPress? What is the underlying need they want to address? What are the implications? When do they expect it done by? How important is it to them? All constraints should be clear. The Strategist should define “done” and determine what an appropriate testing plan would be for the work.
  • Assignment: The Strategist should pass the task to an artisan (designer or developer, usually) based on the nature of the need and the availability and experience of the team members available. The Strategist should assign it in a way that it satisfies the broader project schedule and fits the individual artisan’s personal schedule. When in doubt, the Project Manager can help ascertain who would be the best fit.
  • Execution: The artisan should review the task and ask any additional clarifying questions, then complete the work. When complete the artisan should provide additional information for QA to understand what has changed and where potential issues may lie.
  • Testing: QA should review the work according to the testing plan defined in the Clarification step and refined during execution. QA should ensure that the work meets the need outlined in the original clarified task, but also that the execution meets Cantilever’s standards (for example, our
    Site Standards
  • Release: The artisan should complete the task according to the “Definition of Done”, such as by launching the code or sending something to the client. Once complete, the artisan can mark the task “Complete”.

Task Fields

We want all tasks to contain a standardized set of information. The strategist is the lead accountable party in making sure that each of these things is clear in each task on a project. However, the PM should help, particularly with scheduling and assignment, based on other resource constraints across the company. While there are a lot of fields here, most of them take negligible effort to specify, and they are all critical to ensure that our workflow is smooth.

Standard Cantilever Task Fields

Sherbert the Sheep
Due Date
“In Progress”
Problem/Outcome Statement
“The client’s Wordpress site has 5 plugins with available upgrades. This presents a security risk for the site” / “The client’s Wordpress site has all its plugins fully updated, ensuring that there is no security risk from outdated plugins”
Solution Ideas
“You should be able to update the plugins using the WordPress control panel.”
Definition of Done
• You have updated all the plugins on staging • You have done a quick check to make sure that the site is working properly • You have passed this task to QA
Time Constraints
We want to launch this by Friday so please complete this on staging by Wednesday.
Budget Constraints
The client has one hour left in their budget so let’s try to spend at most 30 minutes on this.
Approval Sub-Tasks
Strategist Approval, QA Approval


Tasks generally require some kind of internal approval before going to the client (outside of QA). This approval ensures that the work does indeed solve the problem, and conforms to the specific requests the client laid out for us. By default the strategist should do this approval, but a creative or technical director may be a more appropriate fit, or approval from both may make sense. If this can be formalized within our software it’s a good idea.


Tasks can become “Blocked” when they cannot proceed before some external requirement is satisfied. For example, a task to update the about page with new headshots is blocked until the new headshots are provided. We should use some sort of indicator in our PM tools to differentiate between blocked and non-blocked tasks.