Due date on task vs. iteration
Featured
Seeking advice or examples on how to break down tasks in the most useful way. How do others strike the balance between using wrike to create a schedule vs. provide collaboration?
For example, we have an important project activity of loading client's data into the software. There is a lot of back-and-forth between our business analyst and technical analyst during this.
We have tried tracking this as a series of dependent tasks. This looks good on the calendar.
- Verify data is ready to import (business analyst)
- Load data (technical analyst)
- Validate and adjust migrated data (both)
- Due to client (milestone)
But in practice, this is a poor fit with the back-and-forth collaboration between the analysts. The conversation might begin with an @mention on the first task to confirm some issue in the data is solvable, the technical analyst might have questions back to the business analyst while processing the data load, and so on.
So we have also tried a single task "load data," with a start date reflecting the business analyst starting to work on verifying the data, and due date reflecting delivery to the client. This is a better fit for collaboration, but doesn't work well from a scheduling pov, because the task sits on the technical analyst's to-do list when it isn't ready for them.
Appreciate perspective on this!
I would set this up as a project with all stakeholders given visibility on that level - and all back and forth for the overarching on that timeline/feed. then have the individual tasks assigned with deadlines as Tasks/subitems as needed.Or setup as blueprint that the new tasks appear upon the dependency of the prior action in your workflow.
I would say the projectmanager must have a look how autonomous the team members are working and fit the design of the project.
One way: I would make a main task for one person. This person is responsible that the complete process is working. Also in this task all communication is stored. Then I would make sub tasks which reflect the timeline. In the subtasks the main task would be linked for reporting.
We have a similar situation where we have multiple people working on a task and we need to keep all communication within that single task. We use automations and workflow statuses to manage this:
We have done similar types of collaboration similar to how Ali Moses described.
Another piece to add on to that, is knowing how your team looks at things. Some of our teams prefer folders. For example when the status changes to "Verifying Data" there is an automation that adds it to the corresponding folder.
Some of our teams are starting to utilize dashboards more, with those processes still leaning heavily on the custom workflow statuses.
Ali Moses I saved your comment because this process makes a lot of sense to me in terms of collaboration within a task, but my question is how do you manage due dates? I think the biggest challenge I see with this method is tasks going overdue because the due date in this sense would be misleading or improperly managed (i.e. business analyst/ tech analyst keeps the task in their court for too long)
Kelsey Rudolph That's a fair point and is something that we've struggled with too. At this time, we are managing it by using an automation to @ assignee or MGMT when tasks have X amount of days until they are due and are in an unacceptable location/status.
Sven Passinger I like your suggestion because it emphasizes and relies on ownership. Have you had success doing this, do your teams use it consistently?
Ali Moses Kelsey Rudolph the method you described seems like an accurate way to model the dates and the work, but a lot of work to maintain, heavily reliant on the analysts keeping wrike very updated and the automations all working exactly as desired. Do you find teams are able to use it consistently, are there issues with work or dates leaking out of the logical structure?
Matt Snyder The method we use is a good amount of work on the front end, but it's pretty stable once you stand it up. If automation breaks for any reason (not usual), I get an email letting me know I need to fix it.
The views we use in our folders are unfiltered since once tasks move to another department, they move to another folder. This allows for full visibility and quick understanding if anything falls out of the logical structure. This does happen very occasionally, but as I said, it's easily identifiable.
Matt Snyder yes we implemented this. It depends mainly on the experience of the project manager to handle this and to decide if the team is ready for such autonomous management. We try to guide all people to be more independent.