Add Default Planned Hours to Queue Details of projects

[#1]

Description - A user should be able to set the the default number of hours that a request will take IN ADDITION to the Default Duration that can be set. Currently, if hours are used to describe the Default Duration, the Request will have a start and end date/time based on those hours. However, Requests should be defined by both the Planned Hours set (e.g. 2-3 hours of working time) as well as the total Duration of the Request (e.g. 3 days). If a user chooses 3 days as the Default Duration, the system assumes that the assignee will allocate 24 hours of working time to complete the Request. If a user chooses 2 hours as the Default Duration, the system assumes that the assignee will be done with the Request in 2 hours time. The system should account for both forms of timing.  

Why is this feature important to you - As Requests are made, the incorrect Planned Hours based on 3 days of duration are assigned to the working team member. These hours, while not accurate, often spike their capacity for the 3 days they are working on the Request. It requires additional management of the Request to update the Planned Hours and this can often be overlooked. 

How would you like the feature to work - An additional field called Default Planned Hours would pre-set the expected hours needed to complete the Request within the timeframe set by the Default Duration. Alternatively, if there was an option to convert a Request to a Task using a Task Template (currently, only Project Templates exist), a user could select a template that has both Planned Hours and Duration preset. 

[#2]

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)

[#3]

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).

[#4]

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.

[#5]

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.

[#6]

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.

[#7]

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.

[#8]

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.

[#9]

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!

[#10]

Currently when you convert an issue to a task there are only a few options that are provided, and none of them are around the columns that live on most Workfront basic project views - (planned hours, duration, assignments, predecessors, etc.)

In the future, if we had the option to align fields for planned hours, duration and assignment to each individual queue topic OR had the option to fill out fields for planned hours, duration and assignment when converting an issue to a task I believe it would help cut down time on schedule/task cleanup.

[#11]

I would love this.

Use Case: I want a request to automatically be assigned to a specific team. It's a 1 hour request, and it needs to be done within a day.

Problem: Under the current configuration, the Planned Hours equal the Default Duration, so it's an 8 hour request and makes the assignee's workload balancer look full. Under the current configuration, all issues' planned hours act like they're "drop everything and this is all you work on until it's done". I'd like more flexible.

There are several Ideas related to this same concept dating back years & I think if they were all compiled, it'd meet the threshold for consideration:
https://experienceleaguecommunities.adobe.com/t5/workfront-ideas/planned-hours-default/idi-p/519953
https://experienceleaguecommunities.adobe.com/t5/workfront-ideas/planned-hours-and-duration-defaults...
https://experienceleaguecommunities.adobe.com/t5/workfront-ideas/allow-system-administrators-to-edit...
https://experienceleaguecommunities.adobe.com/t5/workfront-ideas/add-default-planned-hours-to-queue-...