The idea for this posting came from some support questions that landed with some of my Dynamics 365 colleagues from users of Project Operations, but an interesting topic for any user of Project. When facing a static screenshot and being asked why the duration is what it is, or why did my start date move the answer will always be "it depends" but in the vast majority of cases Project is doing exactly what it should - and based on the order of actions - exactly what you asked it to do!
I'll start with an example - two tasks, in a fixed units based project, both assigned to me and they are apparently identical. But are they?
Next I will add Alex Wilber to my twin tasks and see what happens.
Whoa! These twins obviously are not identical! It is a fixed units project, so it added 16h of work on each task for Alex, and that is ok - but why did the dates change? And 3.25d duration? The first one was pushed out to finish 9/23 and the second says it needs to start 9/10 - and was marked as running late (the yellow highlight shows that if I hover over). To understand the difference let's take a deeper look at the original tasks - and also understand how I created them.
The first task I created as a 2d task, I did not set the dates, I just assigned myself (I started creating this blog post 9/16). Both the project default working template and my resource calendar are Pacific Time. The task start time is 9am.
The second task I created with the start date set for today (9/16) and the finish date set for 9/17. Then I also assigned myself. At this point they appear identical, apart from the calendar icon on the finish date of the 2nd task, which only shows if the cell is either selected or I hover over. Here I selected the cell then hovered over the other finish date to show the difference.
The star in the lower right corner indicates that there is a constraint. If I open up the calendar dialog this shows me exactly what is set.
The task is constrained to finish no earlier than 9/17/21. This happened because I chose the finish date by making an explicit selection, whereas in the first task the finish date was scheduled by project, as the end of the 2 day task that started on the project start date. Best practice when scheduling is to not set any dates that do not explicitly need to be set. The project will flow based on the project start date, the durations, and any tasks set to depend on other tasks. That way if the project needs to be pushed back a week I can just change the project start date and all dates will move. If have constrained any dates they will not move.
Now we know why the tasks behaved differently we can look at why the duration changed to 3.25d when I added Alex, and why it didn't just stay at 2 days. The answer lies in Alex's calendar, and his working day in 9am to 12pm daily - so only 3 hours of work can be completed each day. If I hover over the finish date of the first task I see it completes at 10am.
Alex works 3h per day on the 16th, 17th, 20th, 21st and 22nd, then completes his 16h of effort on the 23rd by working from 9am to 10am. The 3.25d is the calculated duration for the task - with the first two days seeing me complete 16h work and Alex 6h (22h total) then the remaining 10h is another 1.25 * 8 hour days. Currently this is a hard-coded hours per day calculation that Project uses.
The calculation is the same for the 2nd task, except that the finish date is constrained - so it would need Alex to start his assignment at 11am on 9/10 to do the remaining 5 * 3h days to complete by 9/17. As Alex does not have a time machine the PM will need to intervene here and probably removing the constraint is the best solution.
Let's take a look at adding a different resource in place of Alex, and this time I'll choose Lidia.
Interesting! We know why the 2nd task starts earlier as the finish still has the constraint, but that 4 day duration is intriguing - as the task actually looks shorter than the 3.5 day duration we saw earlier? What gives? Time to look at Lidia's calendar.
I've included the left hand part to show what I see in her calendar in my time zone display, as well as the dialog of the calendar settings which shows Lidia's time zone (GMT +1) and the actual local hours she works. In my time zone, which is where the project was created, Lidia can start at midnight, has a 1h break at 3am, then works 4.5h in the afternoon - making a 7.5 hour day. So how does this project get worked? Let's look at the first task, and if I hover over I see the start time as 8am. This 'may' be a bug, and I'd normally expect it to be 9am - still investigating exactly why this is... But we'll go with it for now. On 9/16 I work 8h from 9 to 5, and Lidia works from 8am to her finishing time of 8:30 am, so just 0.5h. On 9/17 I work 8h from 9 to 5 and Lidia works 7.5h, from midnight to 8:30am, less 1h. On 9/20 Lidia also works 7.5h so at that point has completed 15.5h of the 16 - with the final 30 minutes completed on the 21st at 12:30am - and this is confirmed by the finish time if I hover over:
This all turns into a 4 day duration as we have 8.5h on 9/16 (Lidia's 8am to 8:30 plus my 9 to 5) then on 9/17 we have midnight to 5pm, less 1.5h for Lidia's break and the gap between 8:30 and 9am - so 15.5 hours, then 7.5h on 9/20 and finally 0.5h on 9/21. That makes 32. 32 divided by 8 = 4. In this case working across time zones extends the day so the duration calculation can be a little counter intuitive. Two people working concurrently can have 1 day duration and work 16h if each has an 8h calendar - but if they are in time zones that do not overlap then it could be 2 days instead!
With the Project client previously, and Project Online the working time was not taking account of time zones, and customers would need to be creative with setting all working calendars on a consistent time zone. Now Project for the web supports time zones it makes that a lot easier to manage in some ways, but just be careful to understand the different calendars that may come into play - from the initial working time that the Project gets created in - which will drive the overall start time - to all the resources and their calendars. If my plan also had dependencies between resources working on different time zones then you can see how that would have added another layer of complexity.
Posted at https://sl.advdat.com/3lHs5fr
