Using Workflow Statuses Instead of a To Do List

Hi!

I am a PM for a team that writes reports. Each report also has a planning document. Our current space has folders by report name (which are organized into other folders as well) and each project plan is an update of a report. Once we mark a project plan complete, it is automatically moved to a folder-less closed space. The custom fields are very technical orientated rather than being information/tools for PMs.

Our project plans require a lot of administrative work as they are to-do lists with many 1d durations that are scheduled FS yet happen in the same day, no automations and not all of the tasks from the project blueprints are needed for every update. I’m having projects end as soon as a month early which indicates that these plans are inaccurate.

Our task statuses are to do, requested, in progress, completed, on hold, canceled. Our project statuses are planning drafting, planning internal review, planning address internal review, planning XF review, planning address XF review, planning manager final check, planning routing, planning approved, then all of those same stages for reporting, and complete.

I unfortunately do not have space or account admin access, so I have been doing a lot of research on Wrike’s capabilities. I’m convinced my team’s Wrike space has been set up improperly for us to identify bottlenecks and reduce administrative work. We are trying to build new project plan with consolidated tasks, but we are also leaning towards creating a new space with new custom fields that are useful for PMs.

I have proposed the idea of having a space with folders by deliverable lifecycle (planned, in work, approved, obsolete). Each deliverable would have a project plan with the revisions as the parent tasks and the WBS under those. The project plan would move from folder to folder based on the project plan status which would match the folder names. Instead of having tasks that are action oriented, they would be deliverable oriented. For example, the drafting that occurs after the update kicks off would be “Initial Draft”. The status of that task would go through a status workflow of Drafting -> Internal Review -> Finalize for XF Review”. I plan to get my team to start using Wrike’s Approval tool for performing internal reviews.

Resource planning is where I scratch my head… We are updating many deliverables at any given time and writers/reviewers are assigned to multiple projects.

I am hoping there is someone who has experience with leveraging statuses rather than using Wrike as a to-do. If there is, here are my questions:

How does leveraging statuses work for you? Do you recommend it?
I’m aware that assignments can be automated based on status changes. How can I anticipate resource constraints if a person is not assigned to a task until it is ready? I’ve thought about creating RACI type of custom fields with the responsible as the task assignee, but it wouldn’t make the task come up on the ACI’s To Do’s and I couldn’t use workload charts. I know I could make reports but workload charts are a nice tool!
Some people do not need to be assigned to the task at the start or the end of the task, maybe just in the middle. Would I have to manually unassign them when they finish their part so that it doesn’t come up on their To Do or Workload chart?
If people are unassigned, do you reassign them once the task is complete to ensure they get credit for their work? We do not use the time tracking tool in Wrike as it is disabled in our current space, but open to hearing it as a suggestion if it works in reporting.
I do create a lot of analytic reports. Would I have trouble getting metrics using statuses?
Open to any other tips/tricks/recommendations regarding how you may use Wrike to track deliverables that are on an update cadence.

Thank you for reading this very long post!

Find more posts tagged with

workload

tasks

statuses-workflows

resource-management

Project Management

Accepted answers

David Simmington

When I mentioned consistent statuses, I meant consistent within each stage of the workflow, not necessarily identical across every task type. It’s completely reasonable to have different workflows for different deliverables (for example Plan Drafting vs Report Drafting), especially if the lifecycle or typical duration is meaningfully different. In fact, separating those can make reporting clearer because you’re comparing similar work.

The key is that each workflow should follow a predictable progression. For example, something like: Drafting > Internal Review > Address Feedback > Final Review > Approved

If every task that represents a deliverable moves through a consistent sequence like that, you can reliably analyze things like time spent in Drafting vs time waiting for Review, regardless of whether it’s a Plan or a Report. So the consistency isn’t about identical status names everywhere, it’s about having clear lifecycle stages that repeat across similar work, which makes bottlenecks and cycle time much easier to measure.

All comments

David Simmington

You’re not alone… this is a very common evolution in Wrike spaces.

So what I’m hearing is that your team is modeling administrative steps instead of modeling lifecycle. The 1-day FS tasks that all occur the same day are usually a signal that the plan is functioning as a checklist, not a workflow. That’s also why you’re seeing projects end a month early, because the duration model doesn’t reflect actual cycle time.

Leveraging statuses absolutely works, but only when statuses represent meaningful state transitions, not micro-steps. A single deliverable-oriented task (e.g., “Initial Draft”) moving through Drafting to Internal Review to XF Review to Finalized is typically more scalable than separate tasks for each step.

One caution: if you replicate every planning stage and every reporting stage as separate statuses, you may recreate the complexity you’re trying to remove. Sometimes splitting into two simpler workflows (Planning vs Reporting) is cleaner than one long combined one.

On resource planning, this is where many teams struggle. Workload charts only recognize assignees. If you wait to assign someone until the task reaches their stage, you lose forward-looking capacity visibility. The two patterns I’ve seen work:
• Pre-assign primary roles at creation and automate reassignment when status changes
• Or use Effort (hours) instead of 1d durations so workload reflects actual contribution rather than task length

RACI custom fields are helpful for clarity, but they won’t help with capacity forecasting unless those people are actually assigned.

On unassigning after someone finishes their part, I usually let automation handle reassignment when status advances. Reassigning at completion just for “credit” tends to add admin without analytical value unless time tracking is enabled.

Regarding analytics, status-based workflows are actually better for bottleneck identification. You can measure: Time in status (cycle time by phase), Aging WIP, throughput by month, and where items stall most often. That’s significantly more actionable than counting completed checklist tasks.

Before redesigning the space entirely, I’d be curious: How many deliverables are active at once? What metric does leadership care about most (speed, utilization, quality, predictability?) Are planning and reporting truly distinct workflows, or just phases of the same lifecycle?

Jessica Thebaud

Thank you so much for your perspective! I appreciate this so much.

We currently have 44 projects that are either in the planning or reporting stages.
We have 7 writers and 2 reviewers that the projects are split up amongst. We also have 7 specialists that jump around from project to project to perform a couple specific 2d-10d duration tasks.
- How do you retrospectively know who worked on a task if they are not assigned once it has been completed? This may not be an issue if we use the Approve function as there wouldn't be a need to reassign the task to the reviewer, right? Since the Approve function can be it's own function.
We are heavily dependent on predictability for resourcing at this time. We have anywhere from 1-3 projects kick off every week. I know that our reviewers and writers like to have a visual of their current and upcoming tasks. I suppose dashboards that show tasks in the status that comes before could help with that. After looking into job roles, I think there is potential with that as well so we could still use workload charts. (https://help.wrike.com/hc/en-us/articles/360035989794-Job-Roles-in-Wrike)
There hasn't really been any effort put into utilization as higher ups don't believe it is necessary for the writers to track time put into certain tasks. Our project blueprints have effort filled out, but they are not adjusted after the fact. How does effort work for tasks that go through status workflows and assigned to different assignees at different times? I believe Wrike splits up the effort of a task by the duration and number of assignees so I'm struggling to understand how useful it is.
Management definitely has a desire to speed up our process, but this will likely be completed by reducing hand-offs for some administrative tasks that a separate team performs. They want to be able to see where we getting stalled to see if there is any where that we need to make adjustments, but we aren't able to identify that easily right now.
Quality is important. Since we haven't been using the approvals process to perform reviews, we don't have a way to measure this in Wrike.
This is what I'm currently thinking our project plan could become to track a report's entire lifecycle from when it is first drafted to when it becomes obsolete. It isn't too accurate right now as there is a bit of overlap between tasks and I haven't figured out exactly how that would look. Each task would have it's own status workflow to simplify, like you said. Each rev of the report would have the same subtasks.

David Simmington

Thanks for the additional context. The scale you’re describing (44 active projects, 7 writers, 2 reviewers, specialists jumping in) helps clarify the constraints.

A few thoughts based on what you shared:

1. Tracking who worked on something historically
You generally don’t need to reassign completed tasks just to preserve history. Wrike keeps a full activity log showing who was assigned and when changes occurred. That history is usually enough for retrospective analysis. Where approvals really help is exactly what you mentioned: separating work ownership from review responsibility. In that model:

Writer remains the task assignee during drafting
Reviewer is added through the Approval workflow
Approval decisions create a clean record of who reviewed and when

This tends to be much cleaner than reassigning the task back and forth.

2. Predictability and upcoming work visibility
With your volume (1–3 projects kicking off per week), writers and reviewers usually benefit from two complementary views:

Workload charts for capacity forecasting
Dashboards filtered by upcoming statuses so people can see what’s approaching their stage

For example, reviewers might have a dashboard widget showing items in Drafting that are due within the next 5–7 days. That gives them visibility before the task is formally reassigned.

Job roles can help with forecasting if you’re not ready to assign individuals immediately, but most teams eventually move toward assigning the likely owner early so workload projections stay realistic.

3. Effort when assignments change

You’re correct about how Wrike distributes effort. Effort is split across:

task duration
number of assignees

If assignments change during a workflow, the effort allocation recalculates based on the current assignees. That means effort is usually best used as capacity planning, not as a historical measure of who did what.

Many teams in content/report workflows treat effort as a rough planning value (e.g., drafting = 16h, review = 4h) rather than something they update afterward.

If leadership isn’t focused on utilization tracking, the main value of effort will be workload forecasting, not reporting.

4. Identifying bottlenecks

The biggest improvement you’ll likely see from a status-driven model is the ability to measure time in status. Instead of trying to infer delays from task durations, you can start asking questions like:

How long items stay in Drafting
How long they wait in Internal Review
Where work tends to stall

That usually reveals bottlenecks very quickly once the workflow is standardized.

5. Your lifecycle structure

Your idea of treating each revision as a parent task with consistent subtasks underneath is a solid pattern. It keeps the lifecycle visible while allowing each revision to follow the same structure. The one thing I’d watch for is overlap between tasks. When tasks overlap heavily, it can be a signal that the workflow might be better represented as one task moving through statuses, rather than multiple parallel tasks. Many teams start with multiple lifecycle tasks and eventually consolidate them once they see where the real work actually happens.

I’m curious about one more thing that might influence the design: Are your writers typically working on multiple reports simultaneously, or do they mostly focus on one report at a time? That tends to determine whether the workflow should optimize more for capacity forecasting or cycle-time visibility.

Jessica Thebaud

I appreciate you taking the time to give me such in depth responses, thank you!

Yes, our writers are assigned to up to 5 different reports that are in different stages of the rev update. There are review periods or handoff's that allow the writer to work on their other assignments. Our writers tend to get super caught up in these day to day start and due dates when there is any overlap between their assignments. There is so much administrative work required to keep these plans updated and they change on a daily basis (tasks becoming N/A, durations shortening/extending, reviews shorter than anticipated, etc.), it is very challenging to forecast capacity anyway. I’m not saying it isn’t important, but I think how we are currently doing it with our to do project plans is inefficient and unproductive. I don’t currently have an idea as to how we could predict availability weeks in advance using this workflow model, such as when a writer would actually be drafting vs when it is in the internal review. I guess it would be more of a ball park estimate rather than Wrike giving me a date to work with.

Is the historical log of assignees reportable? I know it is visible in the comments but I’ve only seen current assignees in reports.

Due to how our wrike has been set up, my teams management believed that Wrike just simply could not provide us information on bottlenecks, etc.. They had started looking into other project management tools so I’ve been trying to uncover as much as possible about Wrike to prove to them that Wrike is capable! Now that I’ve discovered this workflow model, these are the kinks I need to iron out to sell it to them.

David Simmington

@Jessica Thebaud, thanks for the additional context. The writers juggling 4–5 reports at once explains why the current plans are so hard to maintain. When people are working across multiple deliverables, precise scheduling usually becomes less valuable than effort forecasting. Trying to keep dozens of small tasks perfectly dated tends to create the administrative overhead you’re describing.

A pattern I’ve seen work well is:

• Tasks represent major stages (Drafting, Internal Review, XF Review)
• Effort reflects the expected work for that stage (ex: Draft = 16h, Review = 4h)
• Duration represents the window the work will likely occur, not the exact working time

That allows workload charts to forecast capacity even if the exact timing shifts during the week. In workflows with a lot of handoffs, forecasting is usually more of a ballpark capacity estimate than an exact schedule.

On historical assignments, you’re right that the activity log keeps that history but it isn’t easily reportable. Most teams instead track contribution through approvals, status transitions, and stage ownership rather than reassigning tasks after completion.

Where your workflow redesign will really help is bottleneck visibility. Once stages have consistent statuses, you can start measuring things like time spent in Drafting vs Review and quickly see where work is stalling.

One question: Do the specialist tasks occur on most report revisions, or only occasionally? If they’re inconsistent, there may be an opportunity to simplify the structure further.

Jessica Thebaud

There are three specialist teams we work with. We always work with two of them, very rarely do we not. We are starting to work with the other team of specialists less and less, but they do like to have foresight. Their tasks are indicated by the (if applicable) task that is in the screenshot.

David Simmington

That makes sense. I have a similar situation. When specialist work is usually required but occasionally skipped, I keep those tasks in the blueprint and simply mark them “Not Required” or “Skipped” when they don’t apply. This keeps the structure consistent and avoids the administrative overhead of adding and removing tasks each time.

If those teams want foresight, another option is assigning a job role or team placeholder early, then assigning the specific specialist once the work is ready to begin. That way workload charts can still show upcoming demand without needing the exact person assigned immediately.

Once your workflow stages are driven by consistent statuses, you’ll likely start getting much clearer visibility into how long work sits in each stage, which is usually where bottlenecks become easier to identify. I'm actually working on identifying some bottlenecks in our workflows right now.

Jessica Thebaud

When you say consistent statuses, do you mean consistent statuses across the tasks, consistent to reality or something else? I was thinking of having a different workflow for each deliverable so we could differentiate in reporting, for example Plan Drafting from Report Drafting. Plan drafting can take 1-3 days where report drafting can take 5-10 days.