Teamwork is the lifeblood of project management at Chapter Three. Every project manager uses Teamwork a little bit differently and we each customize the experience to better serve each client. Over time, I’ve found myself re-using a simple task structure that keeps everyone on the same page.
When initially building a site, tasks are more fluid and nebulous as our developers define their own work style. Once the initial development work is completed and we have multiple environments (dev/test/live), we create separate task lists to track overall work volume and progress.
What is a task list?
A task list is a subset of all possible tasks in a project, organized by a common attribute. A task can only be in one task list at any given time. I use task lists to reflect the current state of a task in the production workflow.
I set up 6 different task lists to reflect current status: Inbox, Active Work, Need More Info, Ready for QA, Ready for Deployment, and Backlog. Teamwork can save this tasklist structure as a template, so when you’re ready to go it’s quick and easy to spin up.
Inbox
The dumping ground where every task should start. The primary reason this exists is to give the client one single place to put their requests. Also, it helps to show the project manager “Hey, here is something new! Triage me!”
Active Work
Tasks in this task list are approved to be worked on and scheduled with a production resource. It is crucial that this task list be organized top-to-bottom, in priority order, so that the most important items are tackled first. This method of prioritization forces stakeholders to relatively prioritize the active tasks against each other, eliminating any ambiguity that arises should more than one item be claimed to be the “top priority” or “the highest priority.”
Needs More Info
Any task that is approved to be worked on but is blocked by lack of information lives here and assigned to the person who is blocking production.
Ready for QA
When a task is moved here, it is first assigned to an internal resource before being assigned for client approval. If the work item does not pass QA, it moves back to “Active Work” and is assigned to the original responsible party.
Ready for Deployment
Anything that has passed QA but has not yet made its way to the live site lives here. Once the task is moved up, it is marked as completed and remains here as an archive of everything that has been completed and deployed.
Backlog
Work items that have been scoped and evaluated but are not greenlit live here. Like “Active Work”, this can be prioritized from top to bottom.
Why it works
This structure makes it very clear which tasks are burning against the budget. I empower my clients to actively move the tasks themselves from the Inbox or Backlog into Active Work at their discretion. Also, this structure clarifies which greenlit items cannot be worked on due to a lack of information, and helps to keep tensions as low as possible. Lastly, it provides a great archive of all the ideas conceived over time, and enables stakeholders to revisit them when it becomes strategically advantageous for their organization.
What’s missing
It would be helpful if Teamwork provided a task-level history of when a task was moved between lists. This metadata would be immensely helpful when evaluating velocity between states and bugginess of code.
Only one piece of the puzzle
There is a lot more that goes into managing ongoing work both inside and outside of Teamwork, but these task lists give an excellent bird's eye view of the current state of the project. Other tools in the toolbox include tags, subtasks, reminders and of course comments. No matter how many tools, tips, and tricks you have under your belt, ultimately the most important component of any work item is the level of detail provided in the description.
Fortunately, you can read how to write an effective ticket in Zakiya’s blog post!
