One area that I find Wrike to be weak in is the relationship between planned effort and work done to date. There is no tie between how much work we planned to do and how much has been done so far, and thus how much remains. They are completely isolated pieces of data.
For example, if we have a task that is 4 weeks (20 working days) in duration, and we assign an effort of 40 hours of work to be done in that time, the workload will show that the task requires 2 hours per day for the assigned user (basic effort assignment). If that user doesn’t do anything for the first week, then there are 3 weeks left (15 days) to complete the 40 hours of work; which is fine because they have all 4 weeks to get the work done. However, the workload still shows that the load is 2 hours a day for every day of the duration, including the past days that they did not do anything, and all future days. It is not dynamic, nor does it reflect the difference in planned versus executed effort.
The only way to adjust for this is to manually go in and change the effort assignment to Flexible and redistribute the effort day by day. This is tedious and very inefficient when attempting do this for every task, especially long duration tasks.
I would love for tasks to have a “remaining effort” that can be used on the workload charts. If we look at the example above, given the user did not do any work the first week, the rest of the duration (3 weeks, 15 days) still has a remaining effort of 40 hours. Now the effort per day for the remainder of the duration is 2.667 hours per day (40 hours of effort over 15 working days). There is no way to show this in Wrike.
Let’s take it a step further and say that the user had other work to do and was only able to perform 4 hours of work on this task until the last week of the duration. Now they have to focus heavily on this task to get it done in time, with a remaining effort 36 hours, 7.2 hours per day, for the last week of the task (40 hours of effort - 4 hours worked to date, leaves 36 hours of effort remaining, spread across the last 5 days is 7.2 hours per day).
The workload does not reflect this. It doesn’t take into account how much of the effort has been completed versus how much effort was planned. The workload chart still just shows 2 hours per day throughout. This means that when I am planning additional work, it appears that this user is only at 25% capacity, when in reality he is now at 90% capacity because of this one task for that week.
I want to be able to have the option in the Workload view to show the chart based on remaining effort instead of planned effort. Otherwise, the workload view is only as good as the initially planned effort and does not show the reality of how busy everyone actually is at any given time. To truly see the current workload on users, Wrike needs to base it on remaining effort across the duration and if the tasks are completed already or are still active.
I have used another company’s PM platform in the past that based the workload dynamically on how much work remained to be done. So as the work was performed, the remaining workload either went up or down depending on the reality of how much effort remained. This painted a more accurate picture of users’ workload. And the “health” of the task was based on how far off target that workload was.
I think it would not be difficult to have this option in Wrike. It is simply a calculated data field of effort minus time spent as the basis for the workload chart instead of just the planned effort. The chart would be rendered based on one field versus the other. No change to the rendering engine, just the data fields fed to it. A simple display option could allow the choice of rendering based on planned effort or remaining effort. This would be a huge enhancement to the usability of the workload view.
I have created reports and custom fields in Table view to try to replicate this information, but you can’t create the visual aspect of the Workload view. This needs to be an option of the Workload view and not a columnar report to be useful.