Task Planned Hours 0.25

[TerryHy]

We recently passed our one-year anniversary for Workfront roll-out, and I am now taking a look back at our Project Templates to see if our Task Planned Hours are on point or need adjustment, based on Task average actual hours. Anyway, we are seeing that some of the Tasks that had been given 0.5 (30 minutes) Planned Hours on a Template, really only take 0.25 (15 minutes, or less in some cases). Is there a best practice for a ‘cut-off’ point for planned hours associated to a Task. Is 0.25 too granular? I guess it depends on one’s specific organization/processes, but is it common to have 0.25 Planned Hours associated to a Task in a Template? When we started building our Templates, 0.5 Planned Hours was our lowest Planned Hours. Just looking for some guidance or best practices in this regard, as we audit our Templates and Task Planned Hours. Thanks to the Community for any feedback on this topic.

[EricLu2]

Hi: We use the forecasted amount of time the task takes. Okay, we round up if there is some risk that our forecast is inaccurate. You would create a task in a plan because: 1. It is critical to know when it is going to get done, regardless of how long it takes to do; 2. Some other task is dependent on it, so tracking it is critical to knowing when to trigger a subsequent set of tasks, regardless of how long it takes; Therefore, the accuracy of the duration is important because it tells you when you think it will be done, triggering other work, etc. Therefore, if it takes 0.1 hours to complete the task, then that is what, in my opinion, should be in the template. Thanks, Eric

[AmyZa]

I agree with Eric. We have several tasks in our templates with .25 as the time estimate-most of these have been created to signify some sort of hand off or because there is a significant task dependency that happens at this point. Just because it takes a small amount of time, doesn't mean it isn't important!

[TerryHy]

Thanks to the both of you for your feedback. Will be adjusting audited tasks to 0.25, as applicable. Your explanations helped me to better understand.

[JasonMa]

In my experience, that is too granular. There is no harm in it but it raises the question of what the benefit is. If your template has thousands of tasks (which, since it's WF, having more than 200 starts to make it slow down anyway), then 15 minutes here and there can add up to a substantial amount of time when looking at Planned vs Actual (assuming your workers aren't just rounding up to a half hour on their timesheets anyway). But, if you only have 30 tasks, does it really make a big difference? It all depends on what types of metrics you are trying to generate and how close to reality the people entering their time are to reality. You'll get a lot of answers across the Project Management industry. One of my mentors believed that anything less than 4 hours isn't even worth tracking. Now, I think that is extreme but I've even heard people suggest 8 hours. I also always look and see if some of those tasks are really part of a larger process. For example, the steps to build a server take 15 minutes here, 10 minutes there, but ultimately building a server is a single task and shouldn't be broken up step-by-step in something like WF. So, build server always has 1 hour on a single Build Server task (potentially more based on the number of servers). Also, make sure you are accounting for ramp up/ramp down time when putting in 15 minute tasks. I know there are a lot of studies out there that say that small effort tasks frequently require as much time to ramp up to doing them as they do to actually perform the work. A lot of places like to capture that time. Again, it goes back to whether there is an actual, tangible benefit to you being more granular. If your bosses are over-analyzing the data and attempting to make budget/staffing changes based on just a few minutes of resource availability here and there, then it probably makes sense. But if you are doing it because it is just slightly more accurate and only that, then ask yourself what you will actually do with that slightly better accuracy. Jason Maust Project Manager McGuireWoods