Mary, I like your idea, it brings us most of the way to Gantt Chart processing which I view as the only reliable way to detect and resolve overcommitted resources.
I would like to offer a few suggestions for tweaks to your approach. Please let me know if you like them or not: 1. Instead of keeping separate files for personal and work-related tasks, use the "context" to sort it out. 2. Instead of asking how many hours per workweek, use the already defined "context hours" 3. Instead of (or in addition to) saying that a certain week is overcommitted, also show us that a certain task due April 3 will not be completed until May 15. If an hour is "open" in more than one context, the task to be done in that hour would be the task with the highest computed score from all "open" contexts. This way, when a new task is added, we can see when it will really be done and have an intelligent conversation with whoever is creating the unrealistic deadline. Or, when a more urgent task is added and pushes other tasks out, we could inform people who are waiting on us of what the new estimated completion will be. It seems possible to me that #3 would be a lot more expensive than #1 or #2. If so, I would drop #3. -Dwight Sent via BlackBerry by AT&T -----Original Message----- From: Mary Renaud <[email protected]> Sender: [email protected] Date: Tue, 18 Jan 2011 14:18:54 To: <[email protected]> Reply-To: [email protected] Subject: [MLO] Re: My idea for workload management (Feature request? Easy, ~I think~) Oops... ignore the part that says "0.255102 of a 24 hour day (so a 168 hour week) 42.857136 how much of a 45 hour week?" It was part of an earlier idea I didn't edit out. On 18 January 2011 14:15, Mary Renaud <[email protected]> wrote: > Okay, this is explained the way someone who does not code would explain it, > so please stick with me. > > Since the software already has access to the due date, lead time, and > estimated time any task will take to complete, I was thinking it might not > be too difficult to create a report to do the following... > > Take the total estimated time (using max estimated is probably best since > it's better to plan for the worst case than the best) and divide it by the > total amount of hours in the lead time to create some kind of "Lead Time > Factor" (or any other more intelligent name). > > E.g.: > task 1 > Estimated max: 300h > Due date: April 3, 11:59PM > Lead time: 98.5h (= 4d, 2h, 30min) > (lead time is decreased as today gets into the lead time... > i.e., if the start date was exactly 24 hours ago, the lead time would > = 74.5 instead of 98.5) > Lead time factor would be: 3.045685 (300/98.5; a number above 1.0 means > it's physically impossible... even without sleep) > > > Have a pop-up window (from the tools menu - perhaps under the heading of > "Workload Report" or something similar) in which you can type how many work > hours you have per day or week (whichever makes the overall coding > easiest... I'm not a coder and may be talking gibberish, so correct for my > lack of knowledge as necessary). > > Let's say it looks something like this, for argument's sake: > " [ ] " means entered by user > "=" means calculated by mlo > > --------------------------------------------------------------------- > Work hours per week: [ 45.0 ] > View report for next [ 12.0 ] week > Starting: [ Jan 17 ] > {Workweek factor = 45/168 = 0.267857} > --------------------------------------------------------------------- > > The software then picks out a day and time that is 12.0 weeks away and > works backwards from there, applying the workload factor to the hours > included in the lead time of each task and spits out totals for each week. > > --------------------------------------------------------------------- > *WARNING*: Lead time for "*task 1*" too short for 45-hour workweek { <- > this is determined by dividing the estimated hours of the task by the work > hours entered above } > > > Jan 17 - Jan 23 = 0 > Jan 24 - Jan 30 = 0 > Jan 31 - Feb 6 = 0 > Feb 7 - Feb 13 = 0 > Feb 14 - Feb 20 = 0 > Feb 21 - Feb 27 = 0 > Feb 28 - Mar 6 = 0 > Mar 7 - Mar 13 = 0 > Mar 14 - Mar 20 = 0 > Mar 21 - Mar 27 = 0 > *Mar 28 - Apr 3 = 300.00 hours* > Apr 4 - Apr 10 = 0 > > --------------------------------------------------------------------- > > Let's say there's also a "task 2" with only slightly different parameters > (a different due date and longer lead time), as well as the same "task 1": > > task 2 > Estimated max: 300h > Due date: April 3, 11:59PM > Lead time: 1176.0h (= 49d) > Lead time factor would be: 0.255102 (300/1176) > > 0.255102 of a 24 hour day (so a 168 hour week) 42.857136 > how much of a 45 hour week? > > > So now the Workload summary (which includes all/both tasks) would look like > this: > > Work hours per week: [ 45.0 ] > View report for next [ 12.0 ] week > Starting: [ Jan 17 ] > {Workweek factor = 45/168 = 0.267857} > > > --------------------------------------------------------------------- > *WARNING*: Lead time for "*task 1*" too short for 45 hour workweek ( <- > this is determined by dividing the estimated hours of the task by the work > hours entered above ) > > > Jan 17 - Jan 23 = 0 > Jan 24 - Jan 30 = 0 > Jan 31 - Feb 6 = 0 > Feb 7 - Feb 13 = 0 > Feb 14 - Feb 20 = 42.86 {See workload hours calc explanation below} > Feb 21 - Feb 27 = 42.86 > Feb 28 - Mar 6 = 42.86 > Mar 7 - Mar 13 = 42.86 > Mar 14 - Mar 20 = 42.86 > Mar 21 - Mar 27 = 42.86 > *Mar 28 - Apr 3 = 342.86 hours* > Apr 4 - Apr 10 = 0 > > --------------------------------------------------------------------- > > Workload hours calc explanation: Sum of [for each task: (Lead time factor > / Workweek factor * work hours = 42.86)] > > > So, now you can scroll down your list of upcoming weeks and see if there > are any in which the workload is above your working hours. (Even better if > the window bolds the font for any week where the total workload hour > work > hours per week.) Then you just have to go to tasks in and around that week's > range and fiddle with the lead times, deadlines, etc. and then come back and > check to see if your workload is good enough to prevent bottlenecks. > > (Note, laid out this way, my idea would require keeping a separate file for > home and work so that home tasks don't count in time for work tasks... > but... SO? I would GLADLY maintain a separate work file in order to balance > my work deadlines.) > > > I can think of other little tweaks that would make this even better but > this is the most bare-bones approach I can come up with that would REALLY > REALLY help boost MLO's time management functionality. > > Did that make sense to ANYONE? > > What do you all think? Would this be enough to cover, at least for now, the > workload issues some people are having? > > Andrey (hope you don't mind me calling you by your first name): Is this as > easy to implement as I suspect or are there complications I haven't thought > of? > > Sorry for the long post... again! :) > Mary > -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en. -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
