Projects & Tasks vs Tasks & Subtasks
Hi Wrike Community,
We're a marketing agency that has projects like website designs or campaigns. But we also have much smaller things that reoccur like social media posts. From what we can tell, sub-tasks function very similarly to tasks - they can have assignees, dependencies, duration & effort, track time, etc. Is there something we're missing as far as limitations?
Are there pros and cons of using Tasks & Sub-Tasks instead of Projects & Tasks?
For Example:
Task Social Post
- Sub-Task 1: Content
- Sub-Task 2: Design
- Sub-Task 3: Mockup w/ Caption
- Sub-Task 4: Send to Client for Approval
- Sub-Task 5: Schedule Post
OR
Project Social Post
- Task 1: Content
- Task 2: Design
- Task 3: Mockup w/ Caption
- Task 4: Send to Client for Approval
- Task 5: Schedule Post
Any feedback or advice would be greatly appreciated! Thanks!
Hi Lauren Todd, one difference is the access. You can control the kind of access for a project or folder (who can make a new task, who can delete a task, ...) and with this for all tasks inside. Fo tasks and subtasks this is not possible (they get the access rights from the project/folder).
Also tasks and projects can have different workflows. So you can use it for your workflow organization if you make a difference.
In general I would always use a task for small things and projects for larger goals. What is small and what is large depends on your specific work.
This is a really good question I am struggling with right now myself.
We are an educational toy company so we have the projects for the new products for the year, we have updates on products, packaging, and guides, we have exclusive products which are truncated schedules, and we have hundreds of marketing assets and campaign projects.
The person who initially set up our Wrike infrastructure is a brilliant, detail-oriented, project manager. He created a robust system of blueprints and request forms that create beautiful projects with phases and tasks covering every potential step in our processes. The problem is, that not all of our users understand the beauty and thoroughness.
Putting all the tasks in separately and assigning each task pulls up an alarming list of potentially indistinguishable tasks on a To Do list. As always naming convention is key and if you are naming all the things - great! But when generated from a request form, you are often at the mercy of the user inputting the information. You can put more explicit direction in the request form, but it is still somehow open to interpretation.
After struggling with granular tasks for a few months, I have started using tasks within a project only where there is a handoff from one team to another. When one person will be performing a series of sequential tasks on one aspect of the project, I put them in the Directions field as a checklist. It seems to be working for now. Wish me luck as I start to modify all of our blueprints!
So I think the short answer is, that tasks and subtasks are fantastic, but the efficacy lies with the number of hands in the project. If you can control all the inputs and the users understand the outputs, you are golden. If you need more explicit direction for the individuals working on the tasks, or if there are a GREAT many tasks, take a careful look at the user's view of tasks coming to them.