6

Once I've set up my baseline, I like to use the Tracking view to see schedule slippage (ie: is a project going to be "late"?). The problem occurs when I'm updating the % Complete, but a task that was supposed to be complete (or in progress) has not been started yet, so I leave it at 0% Complete. Project doesn't update the tracking Gantt, so you can't see that the project is "slipping".

How do you handle this?

My "Hack" Workaround

In my Options > Calculation I generally have the following set:

  1. Move end of completed parts after status date back to status date.
  2. Move start of remaining parts back to status date.
  3. Move start of remaining parts before status date forward to status date.
  4. Edits to total task % complete will be spread to the status date.

For tasks that are complete or partially complete, this works great - just fill in the % Complete value, and things jump around, showing you if you're ahead or behind schedule for the remaining tasks.

However, if a task that was supposed to start before the current status date has not even started, I don't know how to make Project push that task forward to the current status date. The only workaround I've found is to assign it a small % complete, such as 1%. Then it moves the remaining part of the task forward to the status date. But this seems kind of hackish to me.

How can I get MS Project 2003 to show schedule slippage on unstarted tasks? Is there a setting / Tool or other feature I need to be using?

Example

Set up a new Project with the following tasks: 1. Task 1 (1d) starts on Monday 2. Task 2 (2d, dependent on 1) starts on Tuesday 3. Task 3 (1d, dependent on 2) starts on Thursday 4. Task 4 (0h, milestone, dependent on 3) Finishes on Friday.

Now, let's set the Status Date to Thursday - we're updating the project plan.

In Scenario 1, Task 1 is 100% complete, but task 2 for some reason is only 50% complete. If we fill that information in, Project will split task 2, and move the second part of the split (the remaining 50%) to start on Thursday. As a result, Thursday's task moves to Friday, and our Friday milestone moves to Monday and we can clearly see the project completion will be late by a day (1 day's slippage).

In Scenario 2, Task 1 is still 100% compete, but task 2 hasn't been started yet (0%). If we fill in the 100% complete for Task 1, and leave everything else at 0%, Project does NOT move Task 2 to Thursday, and as a result there doesn't appear to be any slippage, so at a glance we might conclude the project is still on-time. As a workaround, if I put a 1% in for Task 2, then it does go ahead and splits the task, but that's just a hack to get it to update the timeline, and can't be the only way to do things. At least I hope not. Hence this SE question!

3
  • Hi Tom, welcome to PMSE! I'm not sure to the software your question refers to. Is it MS Project? Besides, bear in mind that very specific questions about tools are discouraged in PMSE (and potentially considered too-localized), as they're likely to be useless 5 years from now.
    – Tiago Cardoso
    Feb 11, 2013 at 19:51
  • Is that so? I guess I should check the Area51 sample questions, because this seemed like the perfect place to post this question. I would be happy to move it over to Stackoverflow or elsewhere...
    – Tom Auger
    Feb 14, 2013 at 15:14
  • Hi Tom, I'm not sure you're question is too localized; however, Tiago points out that it could one day no longer be useful if MS Project changes significantly. I don't think it's a bad post and am happy to leave it opened, but I wanted to address what you said about our Area 51 proposal. We've been in beta now for over two years, so a lot of the site scope has changed since then due to our experiences with Project Management Q&A. Please visit our Project Management Meta site to view some of these past discussions about our site scope. Hope this helps! :)
    – jmort253
    Mar 30, 2013 at 22:44

6 Answers 6

3

If a task that was supposed to start in the past, did not actually start, then that workload (or some of the workload if it was only partially completed) still needs to be done. So the task, or the remaining part of the task needs to be moved into the future.

The act of moving it into the future means that there is more work for the project to do between now and completion, so completion could slip. It is this effect that you want to see correct?

So:

  1. On your status date use the Update Project menu item (on the Project tab in MSP 2010) to move all uncompleted work to a specific point in time (usually tomorrow). This will move uncompleted work into the future

  2. Since 1 does not resolve overallocations, you then need to Level the plan (unless you are using auto-levelling). Having done that MSP will attempt to schedule all remaining work to be done from the update date until completion. This may or may not result in a slippage of your end date

2
  • 1
    Ha! Finally, the right answer - thanks Marv for reviving this old question. Update for MS Project 2003 - Tools > Tracking > Update Project... Then select the "Reschedule uncompleted work to start after." and either let it default to today's date (which moves the tasks to tomorrow) or specify a date, like yesterday (which would start the uncompleted tasks today). I guess this depends on when you are actually updating the status of your project - at the end of the day or the beginning. Note that this WILL also affect other partially complete tasks that might already have moved on update %
    – Tom Auger
    Jan 30, 2014 at 17:47
  • This is the same thing I do, except I try to move the task not necessarily to today, but to when I think we'll actually start. I typically then revisit the assigned resources / duration as well and think about the linkages. Often tasks don't start because there were unknown or unplanned dependencies that are now obvious. I also change my view to show the baseline start and finish dates so that I can see differentiate the current forecast (i.e. slipped tasks) from the original baseline schedule.
    – Adam Wuerl
    Dec 31, 2014 at 0:55
1

Couple of suggestions

if you type a % in, and then change it back to 0%, Project will sometimes move that task right to the project start date instead!

In the absence of any predecessors or a "Start No Earlier Than" constraint, MS Project assumes that you could start that task on the project start date.

if a task that was supposed to start before the current status date has not even been started yet, I don't know how to make Project push that task forward to the current status date.

You can put a "Start No Earlier Than" constraint of status date.

In addition to the Tracking Gantt, you can also use the "Start Variance" and other Variance columns to see schedule slippage.

Couple of cautions

  1. It is not a good idea to make a blanket assumption that all delayed work will start on status date. You need to get buy-in from task resources that they are indeed planning to do so.
  2. You can move tasks that don't have any predecessors (or whose predecessors have completed) to start on status date. Others must be left to follow the dependency logic.
4
  • Hi, thanks for the response. Changing the constraint is not a good solution, because a) it's a manual process that can be quite time-consuming if you have a lot of tasks, and b) it's misleading - instead of communicating that a task was intended to start at a certain time and then has been slipping, you're saying that the task is scheduled to start no earlier than a specific date. I'm sure there's a better way.
    – Tom Auger
    Feb 26, 2013 at 14:32
  • To your caution #1: good point, I hear what you're saying. I don't know how else to do it though - I want to be able to see the project completion date slip to a later date when a task that was supposed to have been started has not yet been started. At least moving all the slipped tasks forward to start on the status date will force all their dependents to slip as well and will push back the project completion milestone. I don't see any other way to let a client know that the project delivery date has changed.
    – Tom Auger
    Feb 26, 2013 at 14:36
  • To your comment #1: yes, but this is silly, since the current status date is well past the project start date. Does Project really think I have a time machine?
    – Tom Auger
    Apr 3, 2013 at 16:20
  • To your comment #2: are you suggesting that I manually set a Start No Earlier Than constraint on each task that hasn't yet started, and manually set it to today's date (there is no "Status Date" option - only a manual date picker)? That's very very time-consuming, and then has to be changed every single time I update my project plan... surely there's a better way?
    – Tom Auger
    Apr 3, 2013 at 16:21
0

Have you tried to baseline the project plan? my suggestion is to use baseline dates and actual dates to show slippage. When you have a critical path shown with predecessors MS project would show the impact of moving dates.

4
  • 1
    I don't understand your answer. My post clearly states that I'm setting my baseline and using a Tracking view. Either you haven't really read my question or I am not understanding your answer?
    – Tom Auger
    Feb 14, 2013 at 15:13
  • I'm trying to understand your problem so this query if Task 1 is 100% complete, but task 2 hasn't started yet (0%) (however was originally base lined to start on Tuesday). Then doesn't that mean the baseline effort is wrong for Task1 or rogue task not discovered or present in the plan?
    – Bruce1979
    Apr 4, 2013 at 14:30
  • not always. What if the resource assigned to Task 2 suddenly became unavailable? What if the job simply didn't get started? In the real world this stuff happens all the time and it would be great to be able to see a project's end date move based on the actuals of your status update.
    – Tom Auger
    Apr 4, 2013 at 22:20
  • I can understand your problem in MS project, however if committed resources are not available or even the job simply didn't get started then this moves the start date for that task, IMHO that's still a future task not a delayed task. However because the startdate has moved there's an impact to end date.
    – Bruce1979
    Apr 5, 2013 at 8:36
0

The package that is starting late should have a predecessor. That predecessor should be slipping which will cause everything after it to slip. This will push the start date out of the succeeding packages.

However, if you hard coded dates for your packages, the project will keep the start date as is. So you need to remove those constraints and have all of your packages "start soon as possible". This will enable the tool to function right.

3
  • I'm not sure I understand your answer. Sure the task has a predecessor - I don't see why the predecessor has to be slipping in order for a dependent task to slip. Task 1: package the product, Task 2: ship the product. if you ship the product late that doesn't necessarily mean that you packaged it late. I'm not hard coding any dates whatsoever other than the project start date.
    – Tom Auger
    Feb 26, 2013 at 14:34
  • I had a bit of trouble interpreting your question so maybe I missed the mark. I'll take another whack at it. Feb 27, 2013 at 11:59
  • Thanks @DavidEspina - sorry if my initial question was confusing - I have tried to rewrite it and be more clear. I hope to get your insights soon.
    – Tom Auger
    Apr 3, 2013 at 16:24
0

The method I use to move activities to progress to current date even they have not been started or partially started is

Select Project tab, Change status date to current date or progress date, select update project, select "Reschedule uncompleted work to start after " & check date, select Entire project & OK. This is similar to progressing in P6

-1

I hope I understood the question. Here I go..

If activity A is started and is getting delayed, then end date needs to be pushed forward by increasing the duration of activity A

If activity A is not started and is getting delayed (and its predecessor activity B is already completed), then lag needs to be added in predecessor of activity A.

1
  • No, that is incorrect. The duration remains the same. The activity is started, then delayed (so no work is being done). Thus the duration must remain the same otherwise you might be billing for hours that were not actually spent on that task or project. You are describing a workaround but I'm looking for the correct solution. The accepted answer from 2014 stands.
    – Tom Auger
    Feb 10, 2021 at 20:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.