Expand my Community achievements bar.

Planned Hours Default

Avatar

Level 7

4/24/17

I want to be able to set a default number of planned hours in the routing rules. Currently, Workfront will assume that the request queue item needs a full FTE between the planned start and completion dates. So in our setup a two week request will have 80 hours. You can change this of course after the issue is created; however, this is a little annoying. It would be better to expose the planned hours value in the routing rules setup. To me setting it to 80 hours is worse than setting it to zero. It has a negative impact on resource management data.

I know this general topic (adding fields to routing rules) has been suggested; however, I feel that this situation takes higher priority over making other fields available in the routing rules because of its negative impact on the resource grid (when looking at issue hours with task hours)

8 Comments

Avatar

Level 3

12/3/18

This is a challenge for us as well. It would be much more useful if the Duration and Planned Hours on an issue were seperate (like they are on tasks) so that you can set the default planned hours for an issue based on the queue topic/routing rules. That way we can have the default duration be 2 days and the default planned hours be .5 hours (as an example).

Avatar

8/3/20

This is an issue for us as well. We need to have duration and planned hours for a queue request. Because of our volume, it may be a two week duration but only 2 hours of planned work. The current setting of 2 weeks = 80 planned hours is crazy.

Avatar

Level 7

8/26/20

This is an issue for our organization as well, and prevents us from pulling issues into the Resource Planning suite of tools, because the planned hours data is unreliable. Like others have mentioned, it would be ideal to distinguish the default planned hours for a queue from the queue's default duration.

For example, our report requests have a 5 day default duration, but they typically on require 2-3 hours of hands-on work. Under the current model, this incorrectly translates to 40 hours of work.

Avatar

Level 2

1/18/21

I am having this issue as well. Our teams manage at least 60% of our work through requests. Not being able to set planned hours and a planned duration essentially renders the Workload Balancer, which we are very excited about, useless to us. Our only option at this time would be to completely reconfigure the way that we work and turn all issues into tasks which would probably add about an hour of work to someone's day every week and require us to change licenses for hundreds of users.

Avatar

Level 1

1/20/21

Hello Workfront,


Our team has also run in to this issue as the majority of our work is managed through requests. Not being able to set planned hours and a planned duration does not allow us to utilize the Workload Balancer.

Avatar

Level 1

1/21/21

This same issue has come up for our team. We were so excited to start using the balancer, but quickly realized after building out new process that the balancer cannot work in our environment unless we can manipulate the duration and hours on an issue. We manage a high volume of work and usually use longer durations, but the work usually only takes a few hours. the current set up calculates an entire week of work for something that really only takes 2-3 hours, making the tool useless.

Avatar

Level 1

2/23/21

We are finding the same issue across our team too and we had to make the choice between having an accurate resource tool or accurate SLAs within requests. Users shouldn't be expected to go in and change the planned hours once completed as this can easily be forgotten and not a great user experience. Duration and planned hours should be separate for incoming requests which would solve this issue. Very supportive of this idea going onto the roadmap!