none
Marking tasks as complete causes unstarted predecessor tasks to go to end of schedul RRS feed

  • Question

  • To simply testing this issue, I made a simple schedule with only a few lines all linked from one line to the next with auto schedule.  All tasks are set to be as late as possible.  No task are started.  If you mark any task as complete, and the predecessor tasks have not started, the predecessor tasks will autoschedule to the end of the project. 

    I know in theory this should not happen.  Predecessors should be complete before the successor can begin.   In reality, we will have some people mark their task as complete, and the predecessor owner has just not yet marked their tasks as complete.  When dealing with 1500 line schedule and many tasks owners who will update their status, this will happen. 

    Is there any solution?  I have sample pictures, but it would not allow me to add yet because my account is not verified.

    Thursday, June 30, 2016 10:28 PM

All replies

  • awhite144,

    Yeah, but you probably won't like the solution. Dispense with the "as late as possible" scheduling, instead, schedule all tasks to be as soon as possible.

    As far as your "theory", well it's not quite correct. When you tell Project to schedule everything as late as possible and you break the link chain by declaring a successor task as complete before the predecessor, then project will move that predecessor task to the end, unless the predecessor task has some progress (i.e. non-zero percent complete).

    Hope this helps.

    John

    Friday, July 1, 2016 12:28 AM
  • When reading your question, my first response is that this can't be happening, but then checked and found it to be so.

    MSP allows you to set a task at 100% complete even if the task is scheduled in the future, in which case it adopts the scheduled start and finish as the actual start and finish.

    MSP also allows you to set a task at 100% complete even if its predecessors have not actually started or actually finished. The unstarted predecessor stays where it is scheduled.

    Of course, I am thinking of all tasks being ASAP, and scheduling from the project start date, which is routine requirement for the critical path method.

    I never, in 20 years, use schedule from the finish date or all tasks ALAP, because it is not good critical path method practice, and I definitely discourage it.

    It's your use of ALAP that is the cause of the problem. I suggest give it up.

    One way around your problem is to give the predecessor an actual start date (tracking table), copy the scheduled start and paste it into the actual start, which will anchor the predecessor.

    Also, don't allow people to mark their tasks as 100% complete unless they have first checked the status of their predecessors.

    Any help?

    Friday, July 1, 2016 12:29 AM
  • Both answers are helpful in confirming my situation and some ideas for solutions.  My challenge is in my long schedule, I understand the deadlines much better than the starting predecessors.  So I can more easily make sure I have good successors to link to and put ALAP to auto schedule.  I completely agree that ASAP makes more sense in the scheduling world, but in our work place, there is a lot of parallel activity that doesn't have clear hard predecessor tasks.  Some items are based on that groups individual resources at that given them, some items may have to find alternative methods to start, even though the "expected" predecessor did not arrive on time.  Basically, I don't have clear start dates, but I know when I need to finish most tasks. (Several deadlines throughout schedules that are MUSTS.)

    I have started to approach the ASAP angle.  I get similar results if I schedule from project finish & ASAP on each task.  Scheduling from project finish causes all summary task to be ALAP.  So it produces similar results as above.  The only method that seems to not show this bug is to schedule ASAP and from project start date.  The bug only presents if there is any ALAP and you mark successor tasks before predecessors have at least started. 

    Seems this should be known issue that would need to be resolved.  Why would a task ignore its successors relationships if they are marked complete.  I would hope this is something that is at least on a list with Microsoft to address at some point.  If anyone else has any insight to help me, feel free to offer.  Seem like ALAP & project finish scheduling is not useful for tracking status unless certain "rules" are followed closely.  It works great for auto scheduling the way I want, but if I cannot track it, it won't help me in the long run.


    • Edited by awhite144 Friday, July 1, 2016 12:51 PM additional details
    Friday, July 1, 2016 12:21 PM
  • awhite144,

    First of all what you are seeing is not a bug, it is simply the way Project works when put into reverse scheduling mode.

    Besides being very confusing to understand, with reverse scheduling there is no margin for error. Everything is scheduled to be ALAP which means that if something happens that upsets that ideal plan, (e.g. material arrives late, a critical resource gets sick, or dozens of other real-life problems), you're in crisis mode. It is much better to schedule forward from a starting point. That allows you to see beforehand where the choke points are in the plan and also know where you have some slack.

    You mention that you have deadlines that are "MUSTS" but that is no different than the majority of plans developed. Have you looked at the Deadline field? That can be very useful for setting those "hard" dates and provides a visual queue.

    As far as having a lot of parallel tasks with no definite predecessors, set those up with a start-no-earlier-than constraint based on estimated time to complete in order to meet the finish date. Do NOT link tasks if there are no clear relationship and don't be adverse to modifying the plan as it unfolds. For example, let's say you have a task the needs material before it can start. Initially it is set up in a normal predecessor/successor sequence. But, the material is late. However, you realize that some preliminary effort on the task can be started before the material arrives. There are a couple of ways to handle that. One is to spit the task into two parts, the first being the preliminary effort and the second being effort that cannot proceed further until the material is in hand. Another approach is to use include a lead in the finish-to-start link between the two tasks (e.g. 1FS-10d).

    Project management is very "hands-on" and needs constant monitoring and revisions to insure end goals can be achieved.

    John


    Friday, July 1, 2016 4:31 PM
  • The only reason I am thinking of it as a bug, is because I cannot understand any logic of why anyone would want what I am seeing happen.  I doubt it was intentional, so I am considering it a bug.  I also understand that conceptually, a predecessor task should never be completed before a successor task was even started.  I know it comes down to proper tracking.  In our case, we are allow multiple users to update their tasks status.  In the cases that user B is better at updating status than user A, we develop the problem seen above.  I doubt the developers were expecting that to happen, but it produces results that I also doubt the developers intended to happen also.  MSP is basically ignoring its successor links just because they are marked completed.  This same situation does not occur in the opposite direction.  Regardless, the software is going to do what it is going to do.   My goal is to make a large 3 year template schedule that gets used for many projects.  I need everything to be auto scheduled to be able to efficiently add new projects without having to go manually set a ton of tasks with constraints.  I need everything except a 5-10 tasks to be freely auto scheduled as a starting point.  It was working perfectly, until I realized this tracking issue was going to cause the problem described.
    Friday, July 1, 2016 5:37 PM
  • awhite144,

    I sense that we're not going to convince you that Project is doing exactly what it should given the scenario you present. Over the years we have seen a number of instances where a user thinks Project should work this way or that way and if it doesn't work quite the way they think it should, then something must be broken. It boils down to whether the user is willing to accept the way it works and perhaps adjust their thinking.

    I'll have to disagree with your statement about Project ignoring a link one way but not the other (i.e. reverse scheduled versus forward scheduled). Keep in mind that in reverse schedule mode, "successor" tasks are not "driven", rather they drive the tasks ahead of them (i.e. looking backward toward the start). So if a later task is marked as complete, it can no longer drive earlier tasks and so they shift over to the next driver, which is likely the end date. Forward scheduling work exactly the opposite. If a later task is marked as complete, it is no longer driven by the predecessor so that link is now null and void. None of the tasks in the chain move because everything is forward scheduled.

    We could probably go on for a lengthy discussion about this issue, but I don't see that as being fruitful for either of us. My suggestion is this, re-structure your plan in forward scheduling mode using the suggestions I made before. And I'm with Trevor on the idea of multiple users updating a large file. That's just asking for trouble, even with normal forward scheduling. I suggest you designate a single person to update progress.

    John

    Friday, July 1, 2016 8:50 PM
  • John,

    I agree, I have to work with what I have got to work with, but I would still like to understand why a developer would intentionally make it work this way (if it was intentional).

    Your statement about a later task not be able to drive previous task if marked complete basically means the link is ignored.  However in forward schedule, the opposite is not true.  If a previous task is marked as complete, it still drives the successor task.  In forward scheduling, why does MSP not shift the successor the next to be driven to the beginning of the schedule since its predecessor is marked complete like it does for reverse scheduling?  The logic going one way is not consistent with the logic going the other way.

    Saturday, July 2, 2016 12:07 AM
  • As a Professional project Planner/Scheduler I completely agree with John and Trevor. Always schedule using ASAP. Scheduling backwards is almost guaranteed to cause a late finish date unless you do a lot of extra work. Scheduling ASAP is quicker, more productive and leads to better results.

    MUST finish by dates requires special scheduling and project management processes. Scheduling backwards eliminates a number of your best tools.

    So:

    1. Schedule from the earliest start date.
    2. Develop and audit your critical path. Where you have resource constraints you need to add links so resources get their work queued.
      TIP don't start tasks until you have everything needed to finish in one go. Don't stop start tasks.
    3. If resources are over allocated you need add links to delay appropriate tasks or find more resource.
    4. Use Deadline dates to define must finish dates. You will get a red diamond in the Indicator whenever a task milestone passes its deadline date
    5. Save a baseline to track progress against
    6. Track accurately. When critical tasks finish late, re-schedule and find extra resources if needed so you catch up as soon as possible.
    7. Start and finish critical tasks on time and by definition you will finish on time.

    There's more to it than this, but without a good critical path the odds are against you. ASAP scheduling is your friend. ALAP is "I'm feeling lucky" scheduling.

    Good Luck!


    Rod Gill
    Author of the one and only Project VBA Book
    www.project-systems.co.nz

    Saturday, July 2, 2016 3:50 AM
    Moderator
  • awhite144,

    Yes, I agree there is an "apparent" inconsistency but consider this. In normal forward scheduling, task durations and links all "push" in a forward direction from a fixed start date. As tasks are completed each link fixes the start date of the successor task. This fixing of the successor start date is important in understanding why the two scenarios act differently.

    In reverse scheduling task durations and links still "push" in a forward direction but it is not from a fixed start date, rather it is toward a fixed finish date. As tasks are completed each link and future incomplete task "holds" the chain of tasks away from the finish date. If a task later in the chain is declared complete (or even started), it's start date is no longer determined by the forward link from the predecessor task, and as a result the predecessor task has nothing to hold it from shifting to the finish date. So yes, in fact the link is ignored.

    Try this, instead of using finish-to-start links which are forward, use start-to-finish links which are backward. The first thing you will get is a warning message about tasks being pushed beyond the finish date, and that's a whole other discussion. But, this action changes the condition in a reverse scheduled plan by causing the predecessor finish date to be fixed by the successor start date. Now, if a task later in the forward chain is completed, the predecessor task's finish date will be "fixed" by the link and no tasks will move.

    If you are still confused or simply don't buy it, then I'm sorry, I tried.

    I think at this point Trevor, myself and now Rod have tried to impress upon you that using reverse scheduling, although Project allows it, is fraught with challenges that are not worth the effort.

    John

    Saturday, July 2, 2016 3:05 PM
  • This topic has been well known about for 20 years. Everyone who uses MSP usually at some point attempts schedule backwards from the finish date and/or ALAP, and after getting badly burned by it realises that it is just plain wrong. Not wrong with the software but wrong with the concept.

    They exist in the software, and may have some very rare occasional uses, but just not practical, never used so how it behaves in various odd situations caused by schedule backwards from the finish date and/or ALAP, who cares?

    The only non-optional, practical, safe, reliable and understandable approach to project scheduling, and especially progress tracking, is the critical path method, and scheduling ASAP and forwards from a start date is fundamental to CPM. If you abandon CPM you don't know where the critical path is so you don't have this vital piece of information which is essential for informed decision making and managing staying "on schedule". Anything else is wingin' it.

    If a successor actually starts before the predecessor finishes then the predecessor link should not be there. It may have been OK when the plan was made but by the time you record the progress on the successor the link is just not true anymore and should be removed before recording actuals.

    In your particular situation, I don't see how it can be logical to expect a successor to be "driving" the predecessor, ie how can a task which is finished in the past be used to force another task to be scheduled even earlier in the past.

    Sunday, July 3, 2016 12:39 AM
  • John,

    I appreciate your effort to find me another solution to use backwards scheduling.  I did attempt the Start-to-Finish links.  It seemed to have some additional problems, however it seems to work in my sample case when using Forward scheduling, all tasks set to ASAP, tied to a hard finish date.  It does not work in backward scheduling, or with ALAP constraints.  Seems to work find with ASAP and forward scheduling  It is basically properly backwards scheduling by using SF links only, but still leaving project in forward mode with ASAP constraints. 

    Trevor,

    I think you misunderstood me earlier.  I do not expect a successor to actually be completed before a predecessor, I just expect someone will track it as completed before the predecessor is marked complete, and I don't want it to throw the schedule in havoc and cause confusion to those tasks owners.  Again, I understand this shouldn't happen with 1 project manager running the schedule, but in our environment, that will not be the case, and it will definitely happen.  John did offer a solution that will work. 

    Everyone,

    I agree we should be working towards using forward scheduling.  I understand it is the best PM method.  I don't need any more advice down that road.  If I can get there someday, I will try.  The problem is my schedule is manufacturing development based on 8 customer due dates, that are fixed.  Customer does not want items late or early (they don't want to store the parts and we don't want to store the parts - within reason +- a week maybe).  So I know several hard deadlines of each project.  If I forward schedule, I have to "make up" several start dates in key areas to all the schedule in order to get the finish dates to work out near the hard deadlines.  Instead, we are backwards scheduling from those due dates so everyone knows when to start.  Everyone already has "slack" built into their duration.  It is challenging to impossible to get ~50 people/organization across a continent (sometimes globe) to agree to put "true" durations so that we can schedule accurately and have slack built into just one location for a PM to use as needed.  Since everyone has built in slack, we reverse schedule, when something is late, someone down the line has to agree to less lead-time.  I don't agree this is best, but I don't see a better solution that can occur immediately.  Does anyone have good solutions to auto schedule 1500 tasks that are primarily based on 1 start date, and ~8 independent finish dates that are not directly related to the 1 start date (maybe 1 is directly related, but not the others).  Again consider that you don't want to finish early or late on those finish dates, therefore you don't want to start on those related tasks too early. 

    Tuesday, July 5, 2016 1:40 PM
  • awhite144,

    Unfortunately you are asking for the holy grail in scheduling and it doesn't exist. Let me offer two final suggestions, one of which I've already touched on.

    First, in your global multi-user environment set up one, and only one, individual that curates the schedule. Along the lines of too many cooks can spoil the soup, having too many users input to a large multi-faceted schedule is just asking for problems (and you've found them). It sounds like with a single person updating the schedule, the issue of tasks moving around due to out-of-sequence updating will go away and you can use your reverse scheduling preference.

    Second, is there a good hard reason you even want/need to use Project? It sounds like your "schedule" is not linked into any kind of network and you need/want more control of the scheduling dates. You may very well find that Excel will meet your needs better. You won't have a Gantt display but if you really need one you could create it in Excel.

    This is probably my last two cents on this issue.

    John

    Tuesday, July 5, 2016 2:36 PM
  • John,

    I really appreciate your time and help.  I hope it hasn't been too frustrating.  Our company has been primarily excel based scheduling, but it has always been each group making smaller schedules and lots of duplication.  We are striving to work towards 1 master schedule that everyone has access to.  The struggle is finding 1 PM across the organization that has the time and capability to manage so many different groups.  In an effort to make small changes, we are using a few PMs.  We are also using another system to share the MSP schedule via a web based portlet.  The web based system allows each user to track their individual tasks, as well as update the status (%complete).  Then when the primary PM opens back into MSP with the updated tasks, we would see this problem.  MSP is primarily what we have to use as our backbone.  We are in piloting phases, so we still have time to use a different approach.  My inquiry and your help has given me more insight on how to approach the problem.

    I appreciate everyone's effort to help me.  Thanks!

    Tuesday, July 5, 2016 5:19 PM
  • awhite144,

    Your appreciation for our help can be shown by marking responses as an answer or giving a vote for helpful responses.

    Yes it has been frustrating because those of us who have used Project for many years have a pretty good idea of what it can and cannot do. Based on that experience we have made suggestions that we feel would help you get the best "bang for your buck". You say you are struggling to find a single person who has the time and capability to manage the plan yet you seem to accept having multiple PMs "manage" the plan. How's that working for you?

    You mentioned a web based portal. Have you considered Project Server or Project Online? I don't work with that aspect of Project but I think it might be a better match for what you want to do. It won't help you with the reverse scheduling issues but it will allow an enterprise approach to your plan.

    John

    Tuesday, July 5, 2016 6:40 PM
  • I think you have to get to the point of asking what is MSP really for?, what does it do best?, what problem does it solve?, what questions does it answer? And then use it in a way that lets it do that job as well as possible.

    One thing it's not for is writing a bus timetable.

    What it is good at is CPM. Good, rigorous CPM answers a lot of questions, mainly how soon can everything start and how soon can everything finish?. This also ensures that you know your project is feasible, that is you know what can be done because you know how it can be done, and for sure you don't want to be doing a project which is not feasible and finding that out when you are in the middle of it.

    Then, it's good for tracking progress and, if done properly, you continue to know where the CP is and continue to confirm that the project is still feasible.

    No project should start until/unless you know how soon everything can start and finish, and know that it is feasible.

    Then you get all of the other information as well, the early dates, late dates and two kinds of float (slack).

    The bars on the chart usually display only the early dates, these are often not the dates that you might intend to start and finish the task. You would intend to start a task on a date somewhere between the early start and late start, ie somewhere during the float. You can't know when you should intend to start a task if you don't know that range.

    It is easy to set up a view so that the the bars display the late dates instead of the early dates.
    You could use spare date fields to hold "intended" dates and display those on the bars.

    All of this is only possible with strict attention to CPM.

    Also, allowing other people to update the status of their tasks using % complete will fail.
    If you are currently conducting a trial to see how that works out I can save you the trouble. Don't do it.

    Recommendations (follow these and most of your problems will disappear):

    Give up scheduling backwards from finish
    Give up use of ALAP constraints.
    Stick to straight CPM, schedule forwards from the start, with FS0 predecessor links only, one of each for every task and no predecessors/successors on the summaries.
    Track progress with status date, actual start, actual duration, remaining duration, actual finish, move remaining parts to status date. All actuals in the past, all scheduled in the future.
    One person in charge, but others to also know and understand how it is done, and be required to prove it.

    Tuesday, July 5, 2016 11:41 PM