Hi: First, I can’t get a proper breakfast here in the Colonies. I would be delighted to visit and enjoy those Lincolnshire sausages at breakfast again. ☺ Your settings show that percent complete is based upon the duration of the task. We believe that progress is made as work is performed. We believe our labor forecast (planned hours) is more accurate than our overall duration estimate. We know it takes about 10 labor hours to do this, but are rather inaccurate as to whether those 10 hours will be expended in a week or two weeks. We have lots of interruptions that would cause our duration to vary widely, but in the end, the labor hours to produce the deliverable remains rather accurate. Therefore, because we trust our labor forecast more than our calendar duration, we calculate percent complete on planned hours. If you believe your ability to forecast calendar duration of the work is far more accurate than the estimated labor hours, then you would want to calculate percent complete on task duration. That means, it might take 10 hours or it might take 20 hours, we’re never really sure, but by golly, we know it will be done in two weeks regardless, then calculating percent complete on Duration is a good idea. The percent complete of the task is used in calculating CPI, which is subsequently used in calculating the EAC. Next thing I saw was that the Performance Index is being calculated on cost. Here are some things to consider: If progress on your project is largely measured by how much money you spend - your projects are external spend intensive, more than labor intensive - then you would want to calculate the Performance Index Method based on cost. If you are spending money (external spend) regularly throughout the project lifecycle, then you should consider calculating the PIM on costs. If your teams sit around and say, we have a budget of $100K, and we’ve spent $45K, so we are about 45% complete, then you have selected the correct setting. Another consideration of using a PIM based on cost - you have to enter the actual cost of expenses. You get actual labor cost from timesheets, but you must manually enter the actual cost of expenses. If you have projects with a lot of expenses occurring throughout the lifecycle of the project, you’re going to be entering a lot of actual costs. If you want to do this easily, check out the AtApp store - they’ve got some things Because we view progress as occurring when labor hours are spent on the work, and our external spend is largely one-time (we buy the hardware and are done with third party spend), we calculate our PIM on labor hours. The external spend is not influential in our interpretation of progress. Spending labor hours to configure, validate, and move the hardware to production is how we measure progress. Now, many will say - um, hey, Eric, the expenditure of labor hours is the same as spending money. What is the difference? Well, I say, you are too right. If you don’t have any external spend on a project, and everyone’s hourly rate is about the same, there is no material difference in choosing a PIM of Hours versus Cost. If you have some people with a high labor rate and some with a low labor rate, progress will be skewed by the people charging time with the high labor rate, if you’ve chosen a PIM of Cost. If the person charging £100/hour charges 10 hours, and the person charging £60/hour charges 10 hours, the former person causes a larger shift in the percent complete than the latter person. If that is how your team works, the lower paid people make less progress per hour of work than the higher paid people, then choose calculating PIM by cost (disregarding external spend). Because we believe that labor hours create progress, and not the bill rate of the people doing the labor, and because our external spend is generally one-time in a project, we look at hours charged as driving progress, not cost. The only projects I can think of (in my narrow experience) where calculating PIM on cost are construction (roads, buildings, bridges) projects, I would think you would want to calculate it based on hours. Next item. If someone has Contribute permission to a project, they can charge time to ANY task in the project. Note that there is no qualification on which tasks they can charge time to. They can charge any amount of time to any task. The task can be closed. They don’t need to be assigned to the task. They can charge more or less than the planned hours. They can charge anything to any task in the project, as long as the project isn’t closed/completed. The trick is to create a report that shows all of the tasks where actual hours is greater than the planned hours. (create a task report with a filter where the Task >> Hours Difference is greater than 0, the number of children is 0, and the task>>status is not equal complete) Then, the resulting report becomes an agenda for meeting with the team to update the forecast. We meet with the people assigned to the task and say - hey, um, we need to update our forecast - you’ve charged X hours and think you’re Y percent complete. How many more hours will it take to complete the task? Then we update planned hours to be larger than actual hours. Many times, we find a person has overcharged one task and undercharged others. That means they are dumping their time in a task (usually the first task to appear in the timesheet for a project). We open timesheets and redistribute their hours for them. Anyway, create that report and schedule it to run weekly. I have that report in a Quality Dashboard that project managers are required to consider every Friday morning. Before they send out their weekly status report, the quality dashboard should show no anomalies. We also found that when people realized we are using timesheets to track progress (by the hour!), most of the ne’er do wells did better in their timesheet accounting. If someone is looking at their timesheet, and doing more with that information than just charging some abstract financial account, well, most people want to do the right thing and timesheet quality improves a little bit. Next, on to the linear percent complete and all that. While there is no doubt text mode code that can calculate that for you (it’s likely a simple division statement), I must admit I am not that good at text mode reporting and simply marvel and the ease with which others toss around text mode code on the reporting forum. Back in the 1970’s when I was doing assembly code, at least we had an assembler that gave us error messages. We had an assembler that told us syntax and run-time errors. WorkFront text mode code is a fantastic black hole. When you run the report, you are tossing your code over a dark wall and if nothing comes back, well, there you are. Back when I did COBOL programming on punched cards (late 1970’s, 1980), because the cost of running a job was so high, we did what was called “bench-checking”. You sat that and visually and cognitively pored over your code looking for anything that might be amiss. That ancient programming skill is mandatory when doing text mode reporting. So, you can understand my love of custom attributes. When you put in a calculation it tells you - real time - if you’ve goofed. In 2015, I suggested to Steve Zobell the most transformative thing they could do to increase the value of the reporting engine was to add syntax checking and meaningful error messages to text mode reports. You can do almost anything using text mode, but the learning curve is strewn with dead-ends, mysterious anomalies, and awash with the tears of frustrated report developers. The custom attribute interface, however, is simplicity itself. While I like a challenge, at my age, you pick and choose your frustrations carefully. I have chosen to not master text mode reporting. There we have it. We calculate the linear hour-based percent complete thusly: [cid:image005.jpg@01D21A31.66181660] We compare the linear percent complete with the reported percent complete and look for anything anomalous. In the end, if you measure progress in terms of how close is the final deliverable to being done, you have to recognize that the relationship between hours expended and percent complete of the final deliverable is rarely linear. If you are knitting a blanket, where the activity of each hour is the same as the last, then yes, hours expended should be linearly proportional to percent complete. In our world, the hours expended do not contribute to the percent complete linearly. WorkFront assumes you are knitting blankets, however, and uses a linear calculation of CPI. I have seen where they are going to allow what we called (in the dark ages) “curve-fitting”. You can divide the timeline for a task into (I think) five groups. For each fifth of the project, you describe the percent complete. Percentile Arbitrary % complete 20% 10% 40% 30% 60% 50% 80% 90% 100% 100% You can describe what percent complete the final deliverable is, when a certain percentage of the planned hours are consumed. In the example above, this means when the team has charged 60% of the planned hours to the task, the percent complete of the final deliverable is 50%. Here is the problem with curve-fitting labor to get a percent complete. I’m going to use the term “rabbit-hole”. It is (thanks, Wikipedia) a metaphor for an entry into the unknown, the disorienting, or the mentally deranging, from its use in Alice’s Adventure in Wonderland. When I’ve been involved in curve-fitting discussions in the past, people start boring down that hole with great passion and time passes and in the end, the curve they produce doesn’t really add value. When would you want to curve fit? The value of curve fitting is not found in short duration tasks. Progress occurs so fast, that it doesn’t really matter if it is 30% complete on Thursday and then 45% complete on Friday. Most projects don’t measure pr
