Change of Planned Hours during a Project

[DagmaraGa]

Hi, What's your practise if your Actual Hours exceeds Planned Hours ? Are users in your company increase Planned Hours in this case to make their reports and project look better? What's the best way to have a possibility to view what Planned Hours was originally, before users started changing it? It is so common to automatically just changed Planned Hours to make it looks better, if your Actual Hours going much on the top of it. Have you had much to do with Baseline to have a better view at original plans on a project? Any tips, advises more than welcome :) Thanks!

[EricLu2]

Hi: We use the baseline to reflect the last approved configuration (cost) of the project. We say a project plan is an elastic model of the future work to be performed, given what we know right now. Therefore, it doesn’t make sense that we would plan to consume fewer hours than we actually have. When the actual hours exceed planned hours, we ask the PM to update the forecast to reflect the new reality. We track that variance by comparing total project planned hours to total project baselined planned hours. That shows us if the PM needs to consume more hours than were originally authorized. If that happens, then we ask they do a change request and get approval for more hours. We don’t track variance at the task level, however, because it is perfectly reasonable to move hours around in a project, so long as they do not forecast more hours than they were originally authorized (in the baseline). We do a lot of comparisons between the last approved configuration (baseline) and the current forecast (planned hours). Does this help? Thanks, Eric

[AnthonyIm]

Like Eric said, Planned Hours should reflect what you think is going to happen on the project and those thoughts can change over time. As long as you are capturing the last approved amount (and that can be by baseline or budgeted hours in the business case), you should be updating the planned hours. If you are adding more tasks or you just realize a few tasks need more hours, make those adjustments. Now once you start comparing to actual hours... are you just comparing them at the end of the project or at different points throughout the project? If it is just at the end, I would just leave the planned hours alone. You thought reality was going to be 1,000 hours and you actually did 1,100 hours. If you are comparing throughout the project, I do make some adjustments based on the work needed. If I'm 50% of the way through and supposed to have 500 hours but really have 600 hours of actuals, I will decide how many hours of work is actually left. If my team can get it done in 400 hours, awesome! If my team is like "No, we still need 500 hours to finish" I will update the planned hours to 1,100 as that is the new reality I'm facing. But like Eric said, I would work with Finance to try and get a change order so the new approved amount is 1,100 as well. I hope that is helpful. LOL!

[LauraRa1]

Yes, this is good! The part that stands out for me is where the PM has to get an approval before going over original planned hours at the project level - this I will put to the core team - I think it might have some legs. Laura Ray Junior Project Manager Bakkavor Information Systems Bakkavor Group West Marsh Road, Spalding, Lincolnshire, PE11 2BB, UK Direct: +44 (0)1775 763 010 www.Bakkavor.com // Laura.Ray@Bakkavor.com<

[EricLu2]

Hi: Good point. There is the question of materiality to consider in changes. Here are the rules we use: 1) We measure variance at the project level, not at the task level. That allows the PM to move hours around between tasks within a project with impunity; 2) We prefer explicit contingency. That means we create a task and load it with all of the contingency hours. When the PM needs to use that contingency, he/she simply reduces the contingency hours and increases task planned hours. I’ve worked contracts with clients where we had more control on use of Contingency, but here, we leave it to the discretion of the PM; 3) In our company, people are authorized to approve spending at certain levels, based on rank. For example, I am permitted to approve the spend of $10K or less. My boss can approve the spend of $50K or less, and so on up the chain. Our contractors (PMs, especially) are not permitted to approve anything - they have a $0 approval threshold; 4) We do not allow people to spend money above their authorized level; 5) When the planned cost of a project exceeds certain thresholds, we require that the PM get approval to spend more - all in line with the approval threshold concept; 6) We divide our planned hours into two buckets - Operating Expense (OpEx) and Capital Expense (CapEx); 7) When the total planned OpEx hours on a project are 5% or greater than the baseline planned OpEx hours, we require them to request permission to spend more money; 8) When the total planned CapEx hours on a project are 5% or greater than the baseline planned CapEx hours, we require them to request permission to spend more money; 9) Also, when the go-live date changes more than thirty days, we require them to get permission to change the schedule; That is how we handle it… Eric

[LauraRa1]

Great stuff Eric, thanks. Our PMs aren’t allowed to add any contingencies - rightly or wrongly. I will use your structure when I put this question to the core team next month. Thanks ☺ Laura Ray Junior Project Manager Bakkavor Information Systems Bakkavor Group West Marsh Road, Spalding, Lincolnshire, PE11 2BB, UK Direct: +44 (0)1775 763 010 www.Bakkavor.com // Laura.Ray@Bakkavor.com<

[EricLu2]

Ha. There are three kinds of contingency: 1) Explicit Contingency - These are line items in the labor plan and/or Expenses called Contingency that are to be used under certain circumstances. The amount of contingency should be determined proportionally to the quality of the forecast. If the forecast is shaky, you need more contingency. If it is something you do a lot, and experience shows your forecast is spot on, you don’t need much contingency; 2) Implicit Contingency - This is where PMs bury contingency in their plan - good luck finding it. If the designer says it will take 100 hours to produce something, the task plan magically shows 150 hours. Review tasks might have 10 hours, when they really only need 5. I used to take estimates from software developers and triple it in my plan - I never trusted the accuracy of their forecast, so I buried my risk mitigation strategy (contingency). 3) Untouchable Contingency - This is contingency built into a project that a PM can’t use. Our fixed assets team, for example, builds in 5% contingency for their purposes. The PM can’t touch it. That contingency, however, appears on all their financial reports, so we are incessantly explaining how our numbers won’t match their numbers, because their contingency isn’t a project cost, and so on. When I worked in Marketing running projects, we always added a modest contingency, but called it something like “Minor Adjustments and Changes”. That way, when you get someone who wants ten revisions of a particular bit of content, you’ve got that covered. You would expect three or four, but sometimes people can’t make up their mind and you can’t predict when that will happen. I can’t imagine running a project with total confidence that the forecast is bang on. If someone could forecast a project and not need any contingency, their prognostication skills could be put to more profitable use in the Stock and Securities market. ☺ Eric

[LauraRa1]

Well you’ve hit the nail on the head - good descriptions - I’m sure our PMs frequently use number 2 ☺ Laura Ray Junior Project Manager Bakkavor Information Systems Bakkavor Group West Marsh Road, Spalding, Lincolnshire, PE11 2BB, UK Direct: +44 (0)1775 763 010 www.Bakkavor.com // Laura.Ray@Bakkavor.com<

[HeidiMa]

We are fairly new to Workfront and wrestling through baselines, updating planned hours, etc and this post is very helpful! We are tracking with baselines as the last "approved plan" and updating the plan when more hours are needed. We are trying to figure out how to handle the "hours that get left behind". For example, let's say you have 100 hours over 4 weeks, allocated to a user to work 25 hours / week to complete the task. Let's say in week 1, the resource was only able to spend 5 hours. The 20 hours remaining does not roll forward, so now the allocations for that resource are missing 20 hours for this task. How do you handle these situations? (which, unfortunately can be pretty common for us!) Thanks! Heidi

[EricLu2]

Hi: We do nothing about it. We want to retain the thought that they didn’t work the 20 hours that week that were planned. Resource Contouring should be released soon and that will let you redistribute assigned hours in a non-linear fashion. I think that is the capability you need to solve the disparity between the assigned and actual distribution of hours. Hope that helps a little… Eric