none
Why does my duration field have this value? RRS feed

  • Question

  • Hi,

    I have a summary task whose duration field does not match the total of all of its sub-tasks' duration field values. I'm sure there's probably an obvious reason for this, but can someone explain to me why this is happening? I've included a screenshot. Also, I have not set the calendar for the summary task to be 24-hour. Should it be if all of its subtasks already are?

    Thanks in advance,

    Mike

    Monday, January 4, 2016 1:56 AM

Answers

  • Mike,

    Does that make sense to me? Yes, because I know that is the way Project works, and has worked since Project was first introduced back in the 90s. Would it be nice to have more than one definition for a day? Maybe for some users, but personally I've never had any problems with the way it works. Once you understand the rules, things go a whole lot easier. For those areas where you need the application to work differently than designed, either find a workaround (e.g. in this case use hours instead of days), or use the wonderful functionality of VBA to customize what you need.

    The obvious way to fix your 10.82 day problem is to set the definition of a day to 24 hours. However, since you indicated previously that this whole scenario is only for one weekend in July, I suggest you leave the definition of a day as the default (i.e. 8 hours), or whatever is applicable to the majority of your plan (e.g. 7 hours). If you really want/need to see the duration for that weekend in terms of days, you can always customize an extra field (e.g. Text1) to show 3.1 days. Remember to check the option to use the formula for calculation of task and group summary rows.

    Text1=DateDiff("h",[Start],[Finish])/24

    If you need to only have that customization show for the tasks on that weekend, you can use VBA.

    I know this isn't what you want to hear, but that's the way it is.

    John

    • Marked as answer by Mike Scalise Thursday, January 7, 2016 4:39 PM
    Thursday, January 7, 2016 2:03 AM
  • Mike,

    It's not going to take 3 days. It is going to take 10.82 days because you have defined a day as being 7 hours and have assigned a 24 hours calendar to it.

    Between 28/07/2016 16:30 and 31/07/2016 20:15, there are 10.82 "blocks" (or "days") of 7 hours
    so 10.82 x 7 = 75.74

    Let's count them.
    On 28/07/2016, 16:30 - 00:00 is 7.5 hours
    On 29/07/2016, 00:00 - 00:00 is 24.0 hours
    On 30/07/2016, 00:00 - 00:00 is 24.0 hours
    On 31/07/2016, 00:00 - 20:15 is 20.25 hours

    7.5 + 24 + 24 + 20.25 = 75.75 hours, and the 0.01 difference in the second decimal place is accounted for by the conversion or rounding from minutes to decimal hours and displaying the underlying data as "days", so near enough.

    This how it works, and this is how it has always worked. The duration of the summary is simply arrived at by calculating how many "blocks" of 7 hours fits into the number of working hours between the start and the finish. The source of confusion, if there is any, stems from a misunderstanding of the rules. Once you know the rules, it's obvious.

    I tend to ignore the display of the summary duration, or just assume it is correct because I know it is.
    You could make a calendar which would be assigned to the summary so that the display of the duration in days matches what you think it should display. This calendar would have just enough working hours in it so that there is only 3 "blocks" of 7 hours in it.

    But my advice is don't bother because it would just be extra trouble for no payoff and might just cause more confusion rather than less.

    Any help?

    • Marked as answer by Mike Scalise Thursday, January 7, 2016 4:38 PM
    Thursday, January 7, 2016 4:28 AM
  • Mike,

    Well you've gotta admit that we are consistent in our responses. That referenced post goes back a few years.

    Okay, let's try this tack to ease your neurons. Two thoughts.

    First, based on previous discussion I gather you have a longer term plan, perhaps a year, with a one weekend special operation buried in the middle. When an individual thinks in terms of "days", they will have a pre-conceived idea of what that means. One person might consider a day to be 24 hours while another, who thinks in terms of working time, considers a day to be 8 hours, or whatever a workday is in their world. However, it would be very unusual for either or those individuals to view a plan such as yours and mentally switch their definition for one isolated weekend. To them a day is a day and they would naturally expect consistency for the whole plan. For the 8 hours per day person, work effort covering 24 hours is going to mean 3 equivalent days of effort, not one day. So....I'm not sure your concern over the value in the Duration field for that one weekend is justified and is it really worth it to find a way to workaround it? If so, then I've already given you a couple of potential solutions - custom field or VBA.

    Here's a second thought. If that special weekend activity in July is important enough to define tasks down to the nearest minute while tasks in the rest of the plan are in days or weeks, then why not break out the special weekend into a separate project file (i.e. have two files, one for the main plan and one for the special weekend plan). They could be linked but that has its own issues.

    Hope this helps

    And, if you feel either or both of us have answered your question or at least been helpful, please consider marking our responses as the answer or with a vote.

    John

    • Marked as answer by Mike Scalise Thursday, January 7, 2016 4:38 PM
    Thursday, January 7, 2016 4:15 PM

All replies

  • Also, by my calculations (if .5 day is treated as half of a 24-hr day for example), the total number of hours is 123, which equates to 5.125 days, which is what I'd expect to see in the summary task duration field.

    Clearly I'm missing something.

    Monday, January 4, 2016 2:03 AM
  • Clearly, yes. The duration of the summary is not the sum of the durations of the tasks. it is the duration from the start of the earliest task to the finish of the latest task.

    Next, your calculation of 0.5 days being half of the 24 hour day is incorrect. The definition of "1 day", ie how many hours that is, is determined by the setting in file, options, schedule, and I suspect that you still have yours eet to 8 hours.

    Any help?

    Monday, January 4, 2016 3:54 AM
  • Hi Trevor,

    Yes this is very helpful. Regarding the .5 days, that makes sense. I had actually previously set my day "Hours Per Day" to 7 in the scheduling options, so .5 in my case would be 3.5hrs. That's good to know.

    Regarding the duration of the summary, I'm still a bit confused. I've included another screenshot, this time with dates and times. I'm still unsure of how Project arrived at 1.57 days. The start date/time of the earliest task is 7/28 at 8:30am and the end time of the latest task is 7/31/16 at 3:00am. That's more than 1.57 days, correct?

    I thought maybe it was because the calendar on the summary task itself was set to None instead of 24 hours, but when I set it to 24 hours, the duration jumped to 9.5 days, which also seems incorrect. Thougts?

    Thanks again,

    Mike

    Monday, January 4, 2016 3:09 PM
  • Mike,

    I think Trevor is counting sheep right now so let me see if I can help.

    There are several things that affect duration and dates in Project. Trevor explained how Project calculates the duration for a summary line and how the definition of a "day" affects the Duration field value. The other things that comes into play are the calendar and the task mode and type (i.e. auto or manual and fixed duration, fixed units or fixed work).

    I see you have specified a task calendar of 24 hours for all subtasks but the summary calendar is "none". That means it takes on the Project Calendar. It's not clear what you intend but if your whole schedule is to be based on a 24 hour calendar then you should set the Project Calendar (Project/Project Information/Calendar) to 24 hours and leave all task calendars as "none". However, if only specific tasks are to be performed on a 24 hour basis and others are to be performed on some other calendar (e.g. standard), then you would probably set the Project Calendar as standard and set the task calendar on only those tasks that are to be performed on the 24 hour calendar. I suspect that may have something to do with the strange value in the Duration field of your summary line.

    Another thing to consider, are all your tasks auto-scheduled? Although unlikely based on your duration values, do any of your tasks have splits?

    What is the task type? Are all your tasks fixed duration?

    Finally, do you have calculation set to auto (File/Options/Schedule group)? If it's not, it could a matter of the summary line didn't recalculate after some editing, so it is "stuck" at 1.57 days. Hitting F9 or re-setting the calculation to "on" will clear the issue.

    Hope this helps.

    John

    Monday, January 4, 2016 4:30 PM
  • Hi John,

    Thanks for the response. I'll share with you a few things about the project:

    1) In terms of task mode, new tasks are set to Auto Scheduled.

    2) I'm using a fixed duration task type for all of my tasks.

    3) I'm only using a 24-hour calendar for the tasks during the go-live weekend. Otherwise, the tasks are using the standard calendar (and then be subject to the resource calendar once I apply the resources, I believe).

    4) I don't think any of my tasks have splits.....

    5) I believe I have calculation set to auto. I've included a screenshot of my options box which should indicate that I do.

    My intention is to just be able to collapse the summary tasks that is "Go Live Weekend" and see a duration of somewhere between 3-4 days (which is the combined total of its subtasks' durations).

    Thanks for your help,

    Mike


    Monday, January 4, 2016 4:51 PM
  • Mike,

    Okay, but what is the Project Calendar currently set to? Standard or 24 hour? And, have you tweaked the standard calendar to work shifts other than the default 8:00am to 12:00pm and 1:00pm to 5:00pm? If so, what are the work shifts (a screen shot of the Change Working Time window showing July 2016 with July 30, 2016 selected)?

    Unfortunately the screen shot doesn't show the calculation setting. There is no "believe" on the calculation setting, it's either "on" or "off". It should be "on".

    As I said, from what you show it's unlikely you have any task splits. They would show up as Gantt bars with dotted lines between splits, if the timescale is set to show that level of detail.

    After checking all this stuff, does your summary line still show 1.57 days? If so, it would probably be easier to figure out what's going on if I could see your file? Would it be possible to send it to me? How large is it?

    John

    Monday, January 4, 2016 5:56 PM
  • John,

    I guess I don't understand exactly what screen would show me whether or not calculation is set to on or off. I didn't see a place for group in File/Options/Schedule group. That's why I just attached a screenshot of the schedule tab.

    The Project Calendar is currently set to Standard. I have tweaked this calendar to be M-F 8:30am-12:00pm and 01:00pm-4:30pm. In addition, I've defined summer hours and a bunch of exception days. I've attached the screenshots for those. Do you see anything that could be contributing to the issue?

    Also, I thought that since I changed each task's calendar to 24 hour, it shouldn't really matter that the project default is Standard. Am I wrong?

    And the file isn't terribly big, but I have notes in many parts of the schedule that are confidential...

    Thanks again,

    Mike

    Monday, January 4, 2016 6:07 PM
  • Mike,

    See my screen shot of the Calculation option. Also, as I mentioned F9 will do an instant recalculation even if the option is off.

    You mention "summer hours", are those different from 8:30AM to 12:00PM and 1:00PM to 4:30PM? If so, what are they and do they encompass the July weekend in question?

    Your question surrounds the value in the Duration field of the summary line and the summary line follows the Project Calendar so yes, the setting of the Standard calendar is very relevant.

    With regard to being able to send the file, if your sensitive data is only in the Notes field, the following simple macro will purge all that information. If there is other sensitive data, the code can easily be expand to include whatever fields are sensitive.

    Sub PurgeNotes()
    Dim t As Task
    For Each t In ActiveProject.Tasks
        t.Notes = ""
    Next t
    End Sub

    John

    Monday, January 4, 2016 6:56 PM
  • John,

    I just checked Calculation and it is set to "On"

    Summer hours are different than 8:30AM-12PM and 1PM-4:30PM. They are:

    M-TH 8:00AM-12PM, 12:45PM-4:30PM

    F: 8:00AM-12PM

    Summer hours do encompass the July weekend in question.

    I have a must start on constraint on the first subtask for 7/28/16 and as you noticed, all of the subtasks are set to the 24-hour calendar. Should I set the summary task calendar to also be 24 hour? As I previously stated, that puts the duration at 9.5 days.

    The fact is, from 7/28/16 through 7/31/16, a resource could perform a task at any point. I thought by setting the tasks' calendar to 24-hour would allow for that.

    Mike

    Monday, January 4, 2016 7:42 PM
  • Mike,

    The constraint will have nothing to do with the duration, it simply constrains a start or finish to a particular date and time.

    Again, without seeing your file I haven't been able to come up with a scenario that will give 1.75 days duration for the summary, but setting the Task Calendar for the summary to 24 hours does, and should, yield a summary line duration of 9.5 days (i.e. there are 67 hours from 7/28/16 8:30AM to 7/31/16 3:00AM and dividing that by 7, as the definition of a "day", yields 9.5 days)

    Yes, if your resources are available 24 hours a day, then setting everything to 24 hours will allow them to perform any task at any time. For a single resource, that is highly irregular, but if your resources are group resources then it is very conceivable that at least one of the resources in the group could be available at any time of the day. Is that what you have?

    John

    Monday, January 4, 2016 11:12 PM
  • "The constraint will have nothing to do with the duration"

    Is that true? I put a must start on constraint to a date that has a different set of working times (Summer Hours --shorter days) than the rest of the year, so setting that constraint would impact duration, no?

    I guess my question is, then, what would be the best way to simply indicate that resources are available 24hrs a day and that any task can be performed at any time? My goal is to have the summary task's duration to reflect the total elapsed time of its subtasks' total duration (around 3-4 days). Is there a straightforward way to simply do that so that I don't need to spend time tracking down why this specific summary task keeps coming up as 1.57 days?

    Again, thank you for all of your help.

    Mike

    Tuesday, January 5, 2016 1:51 AM
  • Mike,

    I repeat, constraints have nothing to do with duration. Duration is the difference in working time between the start of a task and the finish of a task. A constraint simply defines the start or finish, depending on the constraint type. However, if you change a subtask's start or finish by setting a constraint and that task is either the earliest or latest under a summary line, then yes, the duration of the summary line will probably be impacted.

    To answer your basic question, if you want your resource availability to be 24 hours, then I suggest you set the Project Calendar to 24 hours. Also make sure the Base Calendar for all resources is also 24 hours. Then tasks can be performed by any resource at any time. Note that with a 24 hour calendar, working times are pretty much null and void. Is this configuration practical or probable? Not in my mind, but that's what you are asking for.

    What kind of resources do you have that are available 24 hours a day? If it something other than a group resource, I'd sure like to understand what it is. Note, I assume you are talking about labor resources and not machine resources because the latter could very well be available 24 hours a day.

    As far as tracking down the 1.57 days, unless someone else can jump in with a definitive response, the best way to resolve that question is to run the macro I gave you and send me the file.

    John

    Tuesday, January 5, 2016 2:12 AM
  • Thanks, John. Yes, I do have a group resource, so several individuals. This 24-hour schedule would be only for this one weekend. Otherwise, the project will follow the normal, standard schedule.

    Mike

    Tuesday, January 5, 2016 2:55 AM
  • Mike,

    Okay, so did we address your issue or at least clarify some things? I know we didn't specifically determine why you see the 1.57 days at summary level, but as I said, that would require "hands-on" analysis.

    John

    Tuesday, January 5, 2016 5:01 PM
  • Mike,

    Okay, so did we address your issue or at least clarify some things? I know we didn't specifically determine why you see the 1.57 days at summary level, but as I said, that would require "hands-on" analysis.

    John

    John,

    Yes you've definitely been extremely helpful. I've looked at this a bit more and tell me if this makes sense.

    If you look at the screenshot I attached screenshot, you can see that my summary task has a duration of 10.82 days. I believe this is because the number of hours between the start date/time and end date/time is 75.75 hours. If you divide 75.75 hours by the number of hours per day I have defined in the project schedule (which is 7), you get 10.82 days.

    Can you just tell me how this is helpful? I thought by using 24-hour calendars on the summary and subtasks that it wouldn't look at the 7 hours I have defined in the project schedule options. Now, if that 75.75 hours between the start and end times of the summary task were divided by a 24 hour day, I'd have 3.1 days, which is what I expect.

    Does the current behavior make sense to you or do you think it should read 3.1 days? If it does make sense, is there a way I can have project perform the calculation and divide by 24 hours without changing the 7-hour day in the project options?

    As always, thanks.

    Mike


    • Edited by Mike Scalise Wednesday, January 6, 2016 10:46 PM
    Wednesday, January 6, 2016 10:44 PM
  • Mike,

    Does that make sense to me? Yes, because I know that is the way Project works, and has worked since Project was first introduced back in the 90s. Would it be nice to have more than one definition for a day? Maybe for some users, but personally I've never had any problems with the way it works. Once you understand the rules, things go a whole lot easier. For those areas where you need the application to work differently than designed, either find a workaround (e.g. in this case use hours instead of days), or use the wonderful functionality of VBA to customize what you need.

    The obvious way to fix your 10.82 day problem is to set the definition of a day to 24 hours. However, since you indicated previously that this whole scenario is only for one weekend in July, I suggest you leave the definition of a day as the default (i.e. 8 hours), or whatever is applicable to the majority of your plan (e.g. 7 hours). If you really want/need to see the duration for that weekend in terms of days, you can always customize an extra field (e.g. Text1) to show 3.1 days. Remember to check the option to use the formula for calculation of task and group summary rows.

    Text1=DateDiff("h",[Start],[Finish])/24

    If you need to only have that customization show for the tasks on that weekend, you can use VBA.

    I know this isn't what you want to hear, but that's the way it is.

    John

    • Marked as answer by Mike Scalise Thursday, January 7, 2016 4:39 PM
    Thursday, January 7, 2016 2:03 AM
  • Mike,

    Does that make sense to me? Yes, because I know that is the way Project works, and has worked since Project was first introduced back in the 90s. Would it be nice to have more than one definition for a day? Maybe for some users, but personally I've never had any problems with the way it works. Once you understand the rules, things go a whole lot easier. For those areas where you need the application to work differently than designed, either find a workaround (e.g. in this case use hours instead of days), or use the wonderful functionality of VBA to customize what you need.

    The obvious way to fix your 10.82 day problem is to set the definition of a day to 24 hours. However, since you indicated previously that this whole scenario is only for one weekend in July, I suggest you leave the definition of a day as the default (i.e. 8 hours), or whatever is applicable to the majority of your plan (e.g. 7 hours). If you really want/need to see the duration for that weekend in terms of days, you can always customize an extra field (e.g. Text1) to show 3.1 days. Remember to check the option to use the formula for calculation of task and group summary rows.

    Text1=DateDiff("h",[Start],[Finish])/24

    If you need to only have that customization show for the tasks on that weekend, you can use VBA.

    I know this isn't what you want to hear, but that's the way it is.

    John

    I figured that the value was correct based on how Project works. I guess I just don't understand why it's using the 7hr day I've defined in the project options when I've specified a 24 hr calendar for all of the tasks. I don't doubt that the software is performing as it should--I just don't understand yet how a duration of 10.82 days for the summary task helps me at all. It's not going to take 10 days. It's going to take 3 days. I'm sure it's something that I'm missing because, as you say, the software has been this way since the 90s.

    Mike

    Thursday, January 7, 2016 3:15 AM
  • Mike,

    It's not going to take 3 days. It is going to take 10.82 days because you have defined a day as being 7 hours and have assigned a 24 hours calendar to it.

    Between 28/07/2016 16:30 and 31/07/2016 20:15, there are 10.82 "blocks" (or "days") of 7 hours
    so 10.82 x 7 = 75.74

    Let's count them.
    On 28/07/2016, 16:30 - 00:00 is 7.5 hours
    On 29/07/2016, 00:00 - 00:00 is 24.0 hours
    On 30/07/2016, 00:00 - 00:00 is 24.0 hours
    On 31/07/2016, 00:00 - 20:15 is 20.25 hours

    7.5 + 24 + 24 + 20.25 = 75.75 hours, and the 0.01 difference in the second decimal place is accounted for by the conversion or rounding from minutes to decimal hours and displaying the underlying data as "days", so near enough.

    This how it works, and this is how it has always worked. The duration of the summary is simply arrived at by calculating how many "blocks" of 7 hours fits into the number of working hours between the start and the finish. The source of confusion, if there is any, stems from a misunderstanding of the rules. Once you know the rules, it's obvious.

    I tend to ignore the display of the summary duration, or just assume it is correct because I know it is.
    You could make a calendar which would be assigned to the summary so that the display of the duration in days matches what you think it should display. This calendar would have just enough working hours in it so that there is only 3 "blocks" of 7 hours in it.

    But my advice is don't bother because it would just be extra trouble for no payoff and might just cause more confusion rather than less.

    Any help?

    • Marked as answer by Mike Scalise Thursday, January 7, 2016 4:38 PM
    Thursday, January 7, 2016 4:28 AM
  • Yes, this was very helpful--honestly everyone on this forum has been extremely helpful.

    "This how it works, and this is how it has always worked. The duration of the summary is simply arrived at by calculating how many "blocks" of 7 hours fits into the number of working hours between the start and the finish. The source of confusion, if there is any, stems from a misunderstanding of the rules. Once you know the rules, it's obvious."

    I completely get that this is how it works and how it has always worked. I understand what Project does to calculate and arrive at 10.82. So my initial question in all of this has been answered and I appreciate all of your and John's responses.

    My source of confusion is WHY it calculates that way. I'm not trying to be a pain and I know your answer might be "that's just how it works" but there must be a good reason for it. You mentioned yourself that you tend to ignore the display of the summary duration--I would too based on these rules because 10.82 tells me how many 7-hour "blocks" it will take to complete even though I was hoping that by setting the task calendar to 24-hour it would be mean that duration would be continuous, not 7-hour "blocks". But again, if that's how it works then that's how it works.

    One last question. If I change the summary task back to having "None" for a task calendar, then the duration changes from 10.82days to 0.57days. Would one of you mind showing me how it calculates that number?

    Thanks,

    Mike

    Thursday, January 7, 2016 2:07 PM
  • I should also note that I recently came across this discussion that both of you actually contributed to. It's essentially the same question(s) that I had, and answered just as you have. I suppose I just need to accept that that's how duration is calculated and if it doesn't represent the type of information I'm looking for then I won't try to force it to. I can get the information I need from the start and finish dates.

    Thanks again,

    Mike

    https://groups.google.com/forum/#!topic/microsoft.public.project/O7razUbe64Y

    Thursday, January 7, 2016 2:13 PM
  • Mike,

    Well you've gotta admit that we are consistent in our responses. That referenced post goes back a few years.

    Okay, let's try this tack to ease your neurons. Two thoughts.

    First, based on previous discussion I gather you have a longer term plan, perhaps a year, with a one weekend special operation buried in the middle. When an individual thinks in terms of "days", they will have a pre-conceived idea of what that means. One person might consider a day to be 24 hours while another, who thinks in terms of working time, considers a day to be 8 hours, or whatever a workday is in their world. However, it would be very unusual for either or those individuals to view a plan such as yours and mentally switch their definition for one isolated weekend. To them a day is a day and they would naturally expect consistency for the whole plan. For the 8 hours per day person, work effort covering 24 hours is going to mean 3 equivalent days of effort, not one day. So....I'm not sure your concern over the value in the Duration field for that one weekend is justified and is it really worth it to find a way to workaround it? If so, then I've already given you a couple of potential solutions - custom field or VBA.

    Here's a second thought. If that special weekend activity in July is important enough to define tasks down to the nearest minute while tasks in the rest of the plan are in days or weeks, then why not break out the special weekend into a separate project file (i.e. have two files, one for the main plan and one for the special weekend plan). They could be linked but that has its own issues.

    Hope this helps

    And, if you feel either or both of us have answered your question or at least been helpful, please consider marking our responses as the answer or with a vote.

    John

    • Marked as answer by Mike Scalise Thursday, January 7, 2016 4:38 PM
    Thursday, January 7, 2016 4:15 PM
  • John,

    That actually does put my mind at ease, and those are some viable options for tracking down to the minute for that weekend. I'll keep those in mind.

    And yes, I'll surely mark your responses as the answer.

    Thank you,

    Mike

    Thursday, January 7, 2016 4:38 PM
  • Mike,

    You're welcome and thanks for the feedback.

    John

    Thursday, January 7, 2016 5:12 PM
  • Mike,

    To address your first question about "WHY", the answer is that it is the best possible way to deal with the fact that "day" is a concept which is in common use in our language but is inherently imprecise and vague and ambiguous, and means different things to different people. But "month" and "year" are similarly imprecise and vague and ambiguous.

    It is not Microsoft's fault that we have this defect in the language. The guys who originally wrote the software had to deal with this and I for one congratulate them on coming up with the most sensible and practical way to deal with a tricky issue.

    And there is a good reason for it because the way it is addressed in MSP works well, and any other alternative would be worse.

    You can relieve yourself of your confusion if you focus your efforts and concentration on understanding the rules and working with them, rather than concluding that the rules are "wrong" and trying to work against them. It's a zen thing. Just surrender. On our roads the speed limit is 60km/hour. No one knows why, there must be a good reason for it, but one thing is sure and that is that if you drive at 65km/hour you get a ticket.

    Regarding your question about changing the summary calendar to "none", this means that the summary will get the project calendar, whatever that is but you have not told us what it is. However, I can work out what that project calendar probably is because 0.57 days x 7 hours/day = 3.99 hours, so your project calendar has 3.99 working hours (call it 4.0) between 28/07/2016 16:30 and 31/07/2016 20:15

    The 30th and 31st is a Saturday and Sunday so they are probably nonworking days on that project calendar, so the working hours must all be on the 28th and 29th, but we need the start and finish times on those days. If you choose a date/time display option that shows time, and check the working hours for the 28th and 29th, you can tell me what they are and I can do this.

    Let's count them again. If I make the (unlikley) assumption that the standard calendar still has the default times, I get:
    On 28/07/2016, 16:30 - 17:00 (maybe) is 0.5 hours (maybe)
    On 29/07/2016, 08:00 - 12:00, 13:00 - 17:00 is 8 hours, and 8 + 0.5 = 8.5, so this is too many hours, ie not the 4.0 that I am looking for. Tell me the times or I can't do any better than this.

    Thursday, January 7, 2016 10:16 PM
  • I have lost count of the number of times this question has been asked and answered in the last 20 years. That google group that you discovered used to be and still is a "newsgroup" and it started sometime around 1993, at the dawn of the internet.

    Most of the questions that come up in use of MSP fall into about 20 main categories, and the answers and discussions have been repeated over and over. I would say that 90% of the answers have been provided by the same 20 or so people, mainly (hope I don't leave anyone out) Dale, Jan, Julie, Rod, John, Ben, Guillaume and me.

    We have seen a lot of frustration, most of it unnecessary and self-inflicted.

    Thursday, January 7, 2016 10:26 PM
  • Trevor,

    Thank you for the explanation. With an understanding of the rules, I can accept and move on. And your explanation helped greatly with that.

    I figured out the 0.57 days. The Standard calendar has a "Summer Hours" work week, which is

    M-TH 8:00am-12:00pm, 12:45pm-4:30pm

    F 8:00am-12:00pm

    The first task under my summary task has a must start on constraint of TH at 4:30pm, which means that it's really only taking into consideration the 8:00am-12:00pm on Friday and of course not Saturday or Sunday as they are non-working days.

    As you've already conlcuded, 4hrs/7hr work day = 0.57.

    Thanks again,

    Mike

    Friday, January 8, 2016 1:07 AM