Calculating % Complete
Users have noted that the calculations for % complete on the project and sequences is too simplistic. Currently it only looks at the number of shots complete, ignoring tasks and elements.
I think I've figured out how this should work. There is a spreadsheet you can download from here:
http://services.nirvanix.com/shotrunner/sr_admin/documents/SR_Pct_C...
The first sheet shows how the computation is done today, the second sheet shows a more complex example showing a proposed computation. You can change the % complete on the tasks, and mark shots and elements as complete and observe how the % complete for the sequence and the project changes.
Let me know if you think this is correct.
Cheers,
Cameron
2 Posted by Brooks McGinnis on 02 Sep, 2009 06:47 PM
I agree, Tasks should be added together and averaged out to create the % for shots...and following that hierarchy; Shots should be added together and averaged out for the % of Sequences....etc....seq for projects...
Good show...
3 Posted by Tobias Roediger on 02 Sep, 2009 07:15 PM
This makes a lot of sense and the only thing I would add is that dropped shots shouldn't be figured into the totals as a 0% item, rather they should be excluded from the equation.
4 Posted by Juan Carlos Gonzalez-Najera on 03 Sep, 2009 02:17 PM
Cameron,
I think the new methodology makes much sense. I see that you have give equal weight to tasks, shots elements, etc and I think that is very pragmatic. I guess that a more accurate method would weigh maybe a shot more than its underlying tasks/elements, but your approach circumvents difficulties arising form tasks not linked to shots, shots without tasks, etc.
Following up on Tobias' comments, is the status of a task (Holding, Pending,
Complete, etc) considered as to what makes it into the calculation?
Juan Carlos
5 Posted by Nick Jushchyshyn (work) on 03 Sep, 2009 03:02 PM
In my mind ... ideally, each task should have an estimated workload ... No. of hours ... that is expected to complete.
This estimate might be "wrong", but at least it provides a mechanism to weight each task's contribution to the overall project which is important since a file conversion task would likely take much less effort and time than say roto or tracking, so it really shouldn't have the same contribution to overall completion. (If a shot has four tasks: (import, roto, track, composite), it's not 25% complete just because the import has been done)
Now ... each time a user logs time spent on the task, they should be updating their evaluation of percentage completion for the task. This way, if a task is harder than expected and they expect to have one more hour of work after having spent 4 hours on a 3 hour estimated task ... they can log 4 hours of time, and note that the task is about 80% complete. (In other words, hours worked is ignored for purposes of % completion calculation ... just task percentages are used, weighted by estimated task time)
Attached I've modified your second table to show the impact of this type of calculation. Your original proposal ignores any time expectancy for how long (how much effort) each task will require, reporting the project 51% done. Using estimated hours for weighting, the same project is reported at just under 27%.
Hope this helps.
Support Staff 6 Posted by cameron on 04 Sep, 2009 05:18 AM
Thanks guys. I will make another attempt at this model to try to work in task weighting and also leave out omitted shots.
Not trying to make excuses for all my foot-dragging, but the issues are many:
The table shows all the permutations of shots, tasks, elements:
What the computations to the far right of my model do is attempt to include task % completion in the computation, but then override that when things are explicitly marked complete. When an Element or Shot is market complete, that counts as 100% regardless of the completion of the tasks underneath. Elements 'weigh less' than shots because they are rolled up to shots -- but once a shot is marked complete, nothing underneath matters. Elements and tasks for shots are given equal weight. Shots and tasks for sequences are also given equal weight.
If you remove the shot and element completion from the model, then the % complete for the project drops to 23% -- within striking distance of Nick's 26%.
We can't just add up the task completion percentages, because that ignores the fact that shots 001 and 004, and element 03 have been marked as completely done. In other words, the only way you can reliably look at weighted tasks across the project is when the entire project has been fully and evenly populated with tasks weighted tasks.
What I think I will try, is to weight the tasks within an element, or a shot or sequence, but not across the project. The reason is that we need to take into account element and shot completion status -- even if there are no tasks defined under a shot or element. For example: if there are two elements and two tasks on a shot (as we have on shot 002), the elements would count for 50% and the tasks would count for 50%. The 50% for the tasks would be allocated according to their weighting if it exists. If a task is missing a weight, we will have to assume its weight is equal to the average of the weighted tasks. Don't know any other way to do it because no tasks have been put under the elements.
I'll try to work all this into the spreadsheet.
7 Posted by Brooks McGinnis on 08 Sep, 2009 04:54 PM
I thought about a way to weight the shots with out having to create a weighting selector. Instead of having the user/admin set the weight of the shot... make it built in and calculate the weight based upon dates...Start_Date vs Due_Date....and if there is no date make it a default weight value.... I also noticed that so far it does not calculate the completed tasks.
Support Staff 8 Posted by cameron on 08 Sep, 2009 05:24 PM
Hi Brooks, that's a great idea. I'll work that into the spreadsheet model and then we can play with it. If that works out, then we'll implement it (we haven't implemented anything yet.)
Thanks,
Cameron
Support Staff 9 Posted by cameron on 08 Sep, 2009 11:32 PM
So I did a little playing around with weighted tasks. I took a typical number of tasks (3) that might be part of an element or shot, and gave them each a duration in days to arrive at a weight. If a task was missing a duration, then I assigned it a weight equal to the average of the remaining tasks.
I did it only for an element or shot because, remember, we can't reliably look at task weights across the project unless we are totally committed to enforcing it everywhere, all the time.
What I found, and I've included the spreadsheet, is that even when I totally skew the weights of the tasks (14:1) the difference between the resulting weighted % completion vs. unweighted % complete is almost never more than 10%, and most of the time its well under 5%! And, when you roll that up to the shot or sequence level the difference will be even less.
Try it yourself. I'm no math guru, but I'm wondering if doing all these heavy computations is worth a few percentage points in accuracy here?
10 Posted by Nick Jushchyshyn (work) on 09 Sep, 2009 02:07 PM
The main flaw with this logic is assuming the undefined task will fall halfway between the other two in effort. This could work if there are a large number of tasks, but 2 is just not a statistical sample. Plug in a value between 1-5 for that third task to see how the calculation performs in this example. Projects should have defined "default" task duration ... blank should not be possible. If the user skips overriding the default to something more logical for the task they're defining, then that's their choice (see below)
1 - For your post 6, Problems 1-4 are addressed by defining a default task weight (perhaps at the project or studio level). If users are not implementing % completion, then all tasks are either 0% or 100% done and have the same weight, and the weighted calculation simply provides an assessment of % of total tasks (by count) that have been done. Problems 5&6 are exactly what weighting is
2- Tasks should be definable in hours. Days is not high-enough resolution for those that will make use of this feature.
3- Brooks idea for auto-filling "hours" based on a start/end date is pretty good. I would recommend though that the project would need to be configured with a calendar defining working days (i.e. weekends and holidays shouldn't be counted unless artists are expected to work then too) and a default number of working hours per day. Also ... at the time of task entry when start and due dates are entered for the task, the user should have the opportunity to override the hours per day for the task. Example: Compositor is responsible for working on 3 shots. Expected to work 2 hours per day per shot and submit for review/feedback. Each shot may have the same start-end date, but shouldn't be weighted at 6 hours per day per shot.