none
Adding time phased actual work to fixed work task with finish no later than constraint RRS feed

  • Question

  • I am using MS Project Pro 2010, no service packs are installed. I have a 40 hour fixed work task, auto scheduling is on, and I've set a finish no later than constraint 4 weeks into the future. I have assigned a single resource with assignment units of 1.0 and Project correctly determines a 5 day duration and schedules the task from the start of the project with the task start date the same as project start date and 8 hrs per day.

    I switch to task usage view with the time phased time scale set to weeks (middle) and days (bottom) and add the actual work field. Calculate on edit is selected in project options. When I add 8 hours to day one (which matches the planned work), the planned work on the last day of the duration changes to 2 hours and the remaining 30 hours is spread at 10 hrs each to the three days in the middle and the duration changes to 4.2 days. Work stays the same as expected.

    The behavior I expected is that after I add the 8 hours of actual work nothing would change since remaining work is 32 hours and there are 4 days left in the schedule and the work is already scheduled for 8 hrs/day. When I continue to add actual work of 8 hours to each day, the duration continues to go down until I’m adding 8 hours past the duration. What am I doing wrong? This behavior persists whether or not I select the "move unfinished parts…” options in the project options or not. The only way to achieve the expected result is to remove the constraint, add the actual work and then reapply the constraint. I assume I have missed an option that needs to be correctly set to achieve the expected (and desired) result. Thanks.

    Tuesday, January 27, 2015 4:41 PM

Answers

  • Well the first step is to update Project 2010 to Service Pack 2.  That being said I see exactly what you report using Project 2010 and the latest service packs and cumulative updates.  In my opinion, this is an error that appears to be related to the FNLT constraint.  When I remove the constraint, the task acts as expected with the original work distribution remaining as it should.  The task type setting appears to having nothing to do with the issue, as I can reproduce this on Fixed Work or Fixed Unit task types.

    I suggest avoiding the FNLT constraint and use a deadline instead.  I'll also try to bring this to the attention of some Microsoft folks.

    Julie

    • Marked as answer by WMichau Wednesday, January 28, 2015 1:14 PM
    Tuesday, January 27, 2015 9:51 PM
    Moderator

All replies

  • Well the first step is to update Project 2010 to Service Pack 2.  That being said I see exactly what you report using Project 2010 and the latest service packs and cumulative updates.  In my opinion, this is an error that appears to be related to the FNLT constraint.  When I remove the constraint, the task acts as expected with the original work distribution remaining as it should.  The task type setting appears to having nothing to do with the issue, as I can reproduce this on Fixed Work or Fixed Unit task types.

    I suggest avoiding the FNLT constraint and use a deadline instead.  I'll also try to bring this to the attention of some Microsoft folks.

    Julie

    • Marked as answer by WMichau Wednesday, January 28, 2015 1:14 PM
    Tuesday, January 27, 2015 9:51 PM
    Moderator
  • Thanks, Julie.  I thought it was just me.  The reason for the FNLT constraint is that I'm not really scheduling projects but scheduling a single multi-unit resource in a shop environment where many projects are running through at the same time.  I've set up a single resource with units equal to the number of shop personnel and I'm intentionally forcing overallocations (should there be any) by levelling and by not allowing Project to move my tasks any further than externally mandated delivery dates.  From that, I can then see where I will need to alter shop release dates, allocate overtime, hire new workers or subcontract the work.  By entering actual work weekly, I can also see where I might have extra hours to use elsewhere or vice versa.  Unfortunately, a deadline will not prevent Project from moving the tasks beyond the customer provided date when leveling.  This method worked fairly well in Project 2007 even though it's not really what the software was intended for.  I obviously only use a fraction of Project's capabilities.  There's probably better-suited tools out there but this is the one I have and it actually does a great job at it.  I'm sure I can still make it work in 2010 but it looks like I'll have to modify my approach.  I'll leave the question open a while longer and see if I get any additional feedback.  If not, I'll mark it answered and move on.  Thanks, again.

    Tuesday, January 27, 2015 10:11 PM
  • WMichau,

    I tried your scenario shortly after you posted and I thought I had it all figured out so I wrote up a nice explanation but before I hit "submit" I looked at a couple other things and found that my explanation was incorrect. In other words, I also get this strange behavior and I have no idea why Project does what it does given your scenario. However, what I did find is this. If you do not enter actual work values directly into the timescaled grid, but instead enter the % work complete (left side of Task Usage view), Project will correctly populate the work even with the FNLT constraint. It might be a workaround for your needs. So for example, instead of entering 8h into the Actual Work grid for the first day, instead enter 20% for the first day, 40% for the second day and so forth. Project will automatically spread the work across the duration without creating an oveallocation.

    Just a thought. Hope this helps.

    John
    Tuesday, January 27, 2015 11:56 PM
  • Thanks, John.  I'll take a look at that.  I'm also experimenting with changing the FNLT constraints to ASAP constraints while entering actual work then changing it back to see how that impacts the leveling.  Between Julie and you I now know not to waste any more time trying to do it the way I did in Project 2007.  That's a relief in and of itself because this was driving me nuts.  I wish I had a copy of 2013 just to see if it exhibits the same behavior.  Whether this is a "bug" in the software or a calculated departure from 2007 by the MS team, it's telling about my method that no one else discovered it for 5 years.  There must be a better way to do what I've been doing all of this time if I'm one of a very, very few doing it.  At any rate, thanks to you both.  Much appreciated.
    Wednesday, January 28, 2015 1:13 PM
  • No, it is most certainly not just you :-).  I understand your wish to prevent the Resource Leveling command from pushing tasks past the agreed upon delivery dates.  However, constraint and leveling can cause unexpected results.  You are correct, Project does allow tasks to miss deadlines, but, in my opinion, it provides a more realistic result.  You see clearly you are going to miss the deadline and you can take steps to fix the issue if possible.
    Wednesday, January 28, 2015 2:14 PM
    Moderator
  • To answer your question about 2013 - yes, it exhibits the same behavior.  In my opinion, it's a "bug".
    Wednesday, January 28, 2015 2:15 PM
    Moderator
  • I've known for awhile that using the flexible deadline constraint was preferred.  It would be technically more correct and sound.  When a task gets pushed past the hard deadline, this would indicate that I need to work the shop overtime or hire more workers and make the correct adjustments to the working times and exceptions in the resource's calendar.  Then when I re-level it should come back to within the deadline.  The approach I've used in the past was the lazy way.  Setting the hard date made it so that I wouldn't have to re-level or readjust the working times.  I would just make the necessary adjustments to the shop and live with the displayed overallocations.  Going forward, I'm probably going to start doing it the correct way.

    What's allowed me to get away with this for so long (6+ years) is that very few if any of the tasks (separate projects in this case) are linked in any way other than that they're using a common, single resource.  So I only ever have the one deadline constraint for each task.  That's why I say that what I'm using Project for isn't really what it was intended for.  I use it for individual projects in the way that it was intended, so I should have known better.  IMO, giving us the FNLT or FNET constraints and then telling us not to use them is much like the story of the Garden of Eden...

    Wednesday, January 28, 2015 2:32 PM
  • WMichau,

    You're welcome and thanks for the feedback. The only time I ever used the FNLT constraint was when I wanted to see the total slack leading up to individual milestones in each major part of a project. I'd set the constraint on the first major milestone, review the slack, remove the constraint and then set it on the next major milestone, and so on through the project. Other than that, and I'm sure that process is questionable by some, all tasks should be linked and occur as-soon-as-possible, in my opinion. The only constraint type that makes any sense to me is, start-no-earlier-than as applied to a very limited number of tasks, if any, that have no valid predecessor yet are not planned to start when the project starts.

    John

    Wednesday, January 28, 2015 3:24 PM