none
The Magical MS Project Time Machine - Actual Work In the Future RRS feed

  • Question

  • There has been an ongoing problem with MS Project regarding its magical time machine. What do I mean by that?

    Well , how does MS Project seriously allow actual work to be recorded in the future (right of the status date) when a plan is statused? MS Project has functionality to move remaining work from the past to the future (Tools>Tracking>Reschedule Uncompleted Work)

    Why then, does it not have functionality to ensure that work on in progress tasks only occurs in history (to the left of the status line)? When I view the task usage of an in progress task with resoureces assigned, I see actual work hours appearing in the future.

    This situation occurs when the work is undertaken at a more intense rate than was originally planned. Unfortunately MS Project allocates the actual work at a rate per day that it was originally planned at. By way of an example, if the work rate was 2 hours per day before the activity was started. Then you start the activity. 2 days after the start of the activity you move the status date and enter 8 hours of actual work. Well MS Project in its wisdom puts 2 hours per day of actual work over the previous 2 days BUT the rest of the actual work occurs over the future 2 days at a rate of 2 hrs per day. Absolute rubbish! Microsoft you produce the only project planning software that assumes the project manager has access to a time machine. It is very simple concept that even a  6 year old could understand. That is actual work can only occur in the past. The better calculation method would be just to pro-rate the actual work from the activity start date to the status date.

    So I open it up for discussion. If anyone has identified a method (Default settings, Update procedure etc) that can reliably fix MS Project short comings I would be happy to share the method I am currently developing. And I also encourage Microsoft Reps to comment on the magical abilities of the MS Project tool in this area. Incidently MS Project does now not conform to the latest scheudling standard produced by the PMI because of this short coming. Its a simple concept that appears to have been overloked by teh developers: Actual Work In the Past. Remaining Work in the Future.

    We should be able to have a tool that honors this basic rule.

    Regards

    Chris 

     

     

    Tuesday, October 26, 2010 3:41 AM

Answers

  • Ah! We achieve the P6 vs Project Discussion ...  The two tools do work differently, it becomes a matter of learning both tools and how they do things differntly.  In both cases, the tool will give you what you want, if you ask politely and in the correct manner. 

    If we take this to a level of Project Server (a user would actually fill out a time sheet stating the number of hours worked each day, remaining duration, and remaining work required to complete the task).  I do the same thing in the desktop verions.  If Reality is you worked 6 hours on Tuesday and you were scheduled to work 4 then that is what you should enter, 6 hours.  But you also need to tell it "I am progressing differently than as planned" which you evidence through your rebid of remaining work and remaining duration.  No tool has the ability to figure out if you are making better or worse progress than your original estimate... working 6 hours when you were scheduled for 4 only puts you 2 hours ahead if you are **producing** at the same rate as was oringinally intended.  The extra two hours on Tuesay may have been spent just to make sure you were at a given level of progress. No tool exists to make that determination for you.  If you spent 6 hours mowing the lawn instead of 4, no tool can tell if it was just particularly tough going and it took an extra 2 hours, or that you mowed 2 hours of what was on your "to do list" for tomorrow.  For that matter, if you only worked 4 hours ... no tool knows that you have to come back tomorrow to finish what you planned to finish today, or, that the going was so easy that you worked the scheduled 4 hours but also were able to mow much more than orginally planned.

    Keeping track of progress vs %Complete, %Work Complete, and Physical%Complete are all difficult.  Using the methods descibed in the this thread over the past year, you can see how %Complete (a measure of duration) will fall where ever it may, same with %Work Complete.  This is why I recommend use of Physical%Complete... using P%C and manually entering costs (to me) is the only real way to do it.  There's exactly one way to calculate %Complete = (Status Date - Actual Start)/(Forecast Finish - Actual Start)  (ok, Status date may equal time now).  Since the proper method to status a task is to estimate remaining work and remaining duration, you will therefore change the Forecast Finish leaving you a %Complete that may actually decrease compared to last time if you extend your duration.  The Earned Value People have trouble with that, I don't.

    Back to P%C:  If I have 80 bricks to lay and I lay 20 of them, I claim 25% and I do not care about actual duration, remaining duration.... I am 25% complete. Actual Work, Remaining Duration, and remaing work will drive my schedule and cost performance calculations and tell management if I am on schedule and/or on cost.  Where it gets tricky is when the end product is not so tangible such as a Software Requirements Document ... how will I know when I have 25% of the requirements?  Well, you don't ... but you should have past experience telling you how many hours it took "last time" to get to Peer Review, etc.  From that information you can use historical performance to estimate what 100% shoudl look like in terms of hours and duration... you may say, "Last time, when we were at Peer Review it was 37% of the total hours spent on the document" ... Sounds like your P%C might be 37% at Peer Review.

    As a final point, Project does assume 1 hour of work = 1 hour of progress.  I don't know what else you'd expect it to do.  Only the end user can provide sufficient information to the tool to make it useful.

    I think if you investigate use of Physical%Complete, you will find it much more similar to P6 in the behavior you are expecting, especially when you combine this with remaining work and remaining duration.  My opinion is to avoid draging that status bar around, it causes me headaches as well.  You should also investigate the task types... fixed duration, non-effort driven also helps.... incomplete work will roll forward if you enter actual work < planned work.  Vice versa, if you work 6 hours instead of 4, it reduces the future effort.  That is why you have to babysit both RD and RW.


    If you feel this post answered the question, please vote for it. I am also available here:
    msprojectblog.com
    Thursday, July 21, 2011 3:17 AM
    Moderator

All replies

  • Good question. Glad you brought it up.

    Software doesn't produce scheduling nonsense. Project Managers do.

    I will readily defend MS PROJECT on this. Yes, the software allows people to plan and update the plan in a way which produces nonsense, but that does not mean that they are obliged to put in nonsense data, using a nonsense method to produce nonsense results. It is your understanding and updating method which is fault if you do this. Whatever method you might adopt, and this includes any of the basic methods described in some of the well known books and which are also commonly taught in training programs, there are two things which are impossible:

    1. Planned duration in the past (relative to the Status Date).
    2. Progress in the future (relative to the Status Date).

    Any 6 year old and most adults will agree that unless you have a time machine, these two cannot occur. So it is very puzzling that many PMs, schedulers and planners don't seem to get it. I regularly see complete nonsense handed out around tables, and when the nosense is pointed out they try to explain it away.

    Let's establish something right from the start. When you first plan a project it is all about start dates, durations and finish dates. Hopefully, the start and finish dates are derived from a valid critical path network model which is based on predecessors and successors, and does not include date constraints.

    When you update and track, the basic problem stays the same, except that now some of the planned start dates , planned durations and planned finish dates have become actual start dates, actual durations and actual finish dates. In all of the training and consulting work that I do, I advise the adoption of a reliable and foolproof (if only!), simple, 6 step procedure which goes like this:

    1. Save a Baseline
    2. Set a Status Date
    3. Show the Tracking Gantt View
    4. Show the Tracking Table
    5. Show the Tracking Toolbar
    6. Format the Gridlines to show the Status Date as a vertical red line on the chart.

    These 6 steps put you in a position to see what you are doing while you are doing it.

    Then you can nail down the actual start date, if the task has started. The actual start is not the first column on the tracking table for no reason.

    Then you can nail down the actual finish date , if the task has finished.

    If the task has not started, then the start date must be in the future (3rd button, Tracking Toolbar).

    If the task has started but has not finished then the start date must be in the past.

    If the task has started but has not finished, it will have some amount of actual duration which cannot exceed the duration between the actual start date and the status date.

    The actual start date and the actual duration are facts which should be obtainable from the records which must be kept.

    Then there is absolutely no question that any Work or Cost that has occurred must have happened after the actual start date and on the days of actual duration. All of the actual duration, work and cost must be in the past. All of the planned Duration, Work and Cost must be in the future.

    The software allows several things which allow the un-educated user who is insufficiently familar and fluent with the software to produce a tangled mess or nonsense. Some of these things are appropriate, useful and sensible in some special situations. For example, date constraints have uses. FF, SS, and SF have some limited appropriate uses but are hardly ever necessary or advisable. Negative lag is allowed but I strongly discourage it even though it might have an occasional valid use that I can't think of. Zig zag progress lines are part of the package but are just about useless, and prone to mis-interpretation.

    A modern car allows a user to drive at 200 kph in a suburban street, but no one sensible would do it.

    Hope this helps.

     

     

     

     

     

     

     

    Tuesday, October 26, 2010 5:33 AM
  • Hi Trevor

    First, thank you for getting involved in this discussion. I appreciate you taking the time to provide a response.

    I can see we agree on several points. Like the universal law:

    Actual work is in the past.

    Planned (or Remaining) work is in the future.

    I guess the difference might be in our expectations. You see, I expect the software to recognise these universal laws and have them hard coded. I don't expect the user to have to tell MS Project these laws. For example, would you be happy to tell MS Project that there are 7 days in the standard week and their names are Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday? Or that when it performs a forward and backwards pass that it is to use algebra that states 2+2 =4? No I am guessing. You expect the software to recognise these laws and abide by them. Similarly I expect it to recognise that actual work is in the past and remaining work is in the future. There is no case in reality where this is not true.

    So why then does Microsoft ask for user intervention in order to honour this law. Requiring users to move the progress bar in order to get a vertical line on the status date? The actual duration should always be (for an in progress activity) the duration from the actual start date to the status date (taking note of the appropriate calendar). MS Project should have the code adjusted to recognise this. Then when actual work is entered (manually and not via the timesheet functionality) it can be pro-rated over the actual duration as default.

    What MS Project assumes though is that the actual work is accrued as planned. This cause issues when work progresses at a faster rate than was planned, forcing actual work into the future. I will explain this by way of a scenario example:

    I am running a project and Michael is due to write a report. After discussions with Michael we arrive at an estimate that the report will take 20 hours effort and will occur over 2 weeks (Michael has other commitments). Michael is due to start the report on Monday and assuming a 5 day work week, the report is planned to finish a week next Friday. Thus the planned rate of work for Michael is 2 hrs/day.

    On Tuesday afternoon I catch up with Michael in order to update the schedule. Michael is pleased. He states he started on Monday as planned. But he was actually able to complete 6 hours worth of work because some of his commitments were rescheduled for later in the week. He states that he still estimates the report completion to be a week on Friday though (8 days remaining) and that there are 14 hours of work remaining.

    I have the following information:

    Status Date is Tuesday (MS Project defaults the status date to the end of the nominated day)

    Actual Start Is Monday

    Actual Work Is 6 hrs

    Remaining Duration is 8 days (or forecast finish is still a week on Friday) 

    Remaining work is 14 hours

    Lets enter that into MS Project. But lets display the task usage table at the bottom, so we can see where the Actual Work is being time phased.

    First the Status date is set to Tuesday

    Now the Actual Start date for the activity is entered.

    This step all goes well. We can now set the actual duration (even though it is my belief MS Project should recognise that the actual duration runs from the actual start date to the status date). So we drag the progress line accordingly to create a vertical progress line.

    Now lets enter the actual work. The 6 hours is entered. Here is where MS Project has a flawed assumption. It assumes the work progresses at the rate it was planned. Therefore it allocates 2 hours actual work to Monday, 2 hours actual work to Tuesday and 2 hours actual work to Wednesday. But Wednesday is tomorrow!!! It accordingly sets the actual duration to the finish on Wednesday afternoon. Actual work in the future!!! We just told it the actual duration and it goes and changes it.

    Ok so manual intervention is required and we drag back the progress line to make it vertical again. Damn! MS Project adjusts the actual work to be in line with what was planned for that 2 day duration. It reduces the actual work to 4 hours. So we enter 6 hours actual work again and the cycle of despair continues. If MS project simply recognised that the actual duration ran from the Actual start date to the Status date and also recognised that actual work was spread across this duration with a default pro-rated spread, then all would be fine.

    The only way to fix this (it seems) is to enter the actual hours in the Task Usage table as 3 hours on Monday and 3 hours on Tuesday. I don't know about you Trevor, but I don’t fancy doing that across a 1000 activity schedule with a monthly update. I would prefer MS project to recognise the universal law of actual work in the past. Let it set the actual duration accordingly. Then pro-rate the actual hours across that duration.

    Now I might be wrong, there may be a  magical combination of settings that gets MS Project to behave in this way. I have yet to discover them though. Other scheduling software P3, P6, Suretrack behaves in this way by default and is used on the major projects throughout the world. I have yet to see MS Project used to control a a multi-billion dollar project in the same way P6 is used.

    I guess in summary the defaults in the tool need to be setup to honour these universal laws. Otherwise because of its apparent ease of use, it promotes bad scheduling practice. PMs can pick up the tool and start creating pretty pictures that have no basis in reality. Microsoft has a responsibility to ensure its product honours these universal laws by either hard coding or providing default settings that the user can override should they wish to ignore reality. The out of the box product needs to align with the scheduling standard , otherwise it just promotes bad practice.

    If anyone has a macro or a set of default settings to get Microsoft project to behave as other packages do (honouring these universal laws) then please post.

    Thanks Trevor for the input. Like you, I wish to create a fool proof system to stop the nonsense in MS Project schedules. The more this can be based on hard rules in the system, rather than user intervention, the better.

    Regards

    Chris

     

     

    Tuesday, October 26, 2010 11:47 PM
  • Hi Chris,

    Though I recognize the iron logic of your argument, it should be noted that there seems to be a project management method that actually relies on the "time machine": Using the "Progress Line". I never use it because like you, I prefer the split between past and future, but through the years, I have read many posts asking about it, so I know it is used by scores of people.

    From there on, you can't blame MSFT to give the users the choice between using the progress line or Chris's law of nature - which by all means is only a few clicks away.

    Hope this helps,

    Wednesday, October 27, 2010 6:08 AM
    Moderator
  • Excellent information in these posts.  You can configure MS Project to avoid most of this nonsense.  Of course, follow Trever/Jan's methods (that's the way I do it too).

    Not seeing the verions of Project you are using, so here is it for both P2010 and earlier verions:

    Earlier Versions:  Tools/Options/Calculation (tab):

    Select Move End of Completed Parts after the Status Date back to the Status Date  [fixes "future work"

    Select:  Move Start of remaining parts before the status date forward to the status date. [fixed incomplete work in the past]

    Even with these items selected, you still need to enter actual start/finish dates, remaining durations, and remaining work as stated in the other posts.

    P2010:

    File/Options/Advanced  scroll to the bottom and you will see the same settings described above.

     


    If you feel this post answered the question, please vote for it. I am also available here:
    msprojectblog.com
    Wednesday, October 27, 2010 5:04 PM
    Moderator
  • Hi Jan

    Thanks for the contibution.

    I understand that some Project Managements may appreciate (or unwittingly use) the Time Machine affect. Especially in construction projects where they can present an un-impacted schedule to the client and state everything is on track. In fact those schedules are not representation of reality. And perhaps it is the clients fault for not being educated in such things. What is the principle aim of a schedule? To forecast the project completion date. If the settings don't support that straight out of the box then what is the result? Lots of poor quality schedules.

    I simply don't agree that MS Project gives you the "choice". I feel it just doesn't address it. It relies on the user to make that Progress line straight in order for the schedule to represent some form of reality. I would consider that poor user interface, requiring the user to compensate for a poor scheduling engine. If everyone makes that line straight all the time to have good quality schedules.....then perhaps it should be an option in the Scheduling settings under the Options tab? That would demonstrate that Microsoft recognises a good method of scheduling (according to the standard) and allows the user to setup the system to promote good practice by default rather than require user intervention. That is what I consider providing a choice to be.

    How much effort is spent around the world making that little line straight because Microsoft doesn't offer a setting to honour a basic universal law?

    Chris

    Wednesday, October 27, 2010 11:18 PM
  • Hi Jim

    Thank you for your contribution.

    I have those settings established and its very important to do so. But they are not the entire solution. (I also have unchecked the "updating tasks status updates resource status")  

    Even after straightening up that progress line on a fixed duration, in progress task, as soon as I enter actual work at a higher rate than initially planned, MS project modifies the actual duration and places work in the future. Have a go a setting up the example I gave about Michael writting a report. MS Project has an underlying assumption that actual work is accrued at the rate it was planned. A better assumption would be that actual work is accrued on a pro rated basis, over the actual duration, which is hard coded to run from the actual start date to the status date.

    Have a go at it. You may have the soultion to this. They only way I have to fix this is to enter actual work by timeperiod in the task usage or resource usage tables. A big job on a 1000 line schedule. A single column entry is turned into 4 individual entries for a project on a 4 weekly update period.

     

    Wednesday, October 27, 2010 11:29 PM
  • Hi,

    I should have been a bit clearer. When I say some uers use the progress line to manage their projects, they do not necessarily straighten it out. They just look at it to see where they are delayed and where they are ahead of (original) schedule. I agree with you in that Project SHOULD have the forecast of the end date as first aim, but believe me, some users don't use it like that. And I can well and duly live with the fact that Project gives the choice. It's like using %Complete for tracking: very lousy method, but many users want to use it, so Project allows it. Microsoft is not Big Brother, and I'm glad it isn't.

    Greetings,

    Thursday, October 28, 2010 6:32 AM
    Moderator
  • Hi, I'm challenging the same problem as you since I move from P6 to MS Project for a new Project and i'm really happy to have find your post.

     

    Did you manage finally to spread the Actual Work evenly in the past ?

     

    Regards

     

    Mathieu

    Wednesday, July 20, 2011 8:38 AM
  • Hi,

    The answer is that you do not have to do anything special to "spread actual work evenly in the past"; you just shouldn't put Actual Work in the future - for instance by entering a %Complete larger than what can be reached by working as planned. When entering %Complete Project does what you ask for, no more, no less, and it ignores current date or status date.

    Greetings,

    Wednesday, July 20, 2011 9:57 AM
    Moderator
  • Ah! We achieve the P6 vs Project Discussion ...  The two tools do work differently, it becomes a matter of learning both tools and how they do things differntly.  In both cases, the tool will give you what you want, if you ask politely and in the correct manner. 

    If we take this to a level of Project Server (a user would actually fill out a time sheet stating the number of hours worked each day, remaining duration, and remaining work required to complete the task).  I do the same thing in the desktop verions.  If Reality is you worked 6 hours on Tuesday and you were scheduled to work 4 then that is what you should enter, 6 hours.  But you also need to tell it "I am progressing differently than as planned" which you evidence through your rebid of remaining work and remaining duration.  No tool has the ability to figure out if you are making better or worse progress than your original estimate... working 6 hours when you were scheduled for 4 only puts you 2 hours ahead if you are **producing** at the same rate as was oringinally intended.  The extra two hours on Tuesay may have been spent just to make sure you were at a given level of progress. No tool exists to make that determination for you.  If you spent 6 hours mowing the lawn instead of 4, no tool can tell if it was just particularly tough going and it took an extra 2 hours, or that you mowed 2 hours of what was on your "to do list" for tomorrow.  For that matter, if you only worked 4 hours ... no tool knows that you have to come back tomorrow to finish what you planned to finish today, or, that the going was so easy that you worked the scheduled 4 hours but also were able to mow much more than orginally planned.

    Keeping track of progress vs %Complete, %Work Complete, and Physical%Complete are all difficult.  Using the methods descibed in the this thread over the past year, you can see how %Complete (a measure of duration) will fall where ever it may, same with %Work Complete.  This is why I recommend use of Physical%Complete... using P%C and manually entering costs (to me) is the only real way to do it.  There's exactly one way to calculate %Complete = (Status Date - Actual Start)/(Forecast Finish - Actual Start)  (ok, Status date may equal time now).  Since the proper method to status a task is to estimate remaining work and remaining duration, you will therefore change the Forecast Finish leaving you a %Complete that may actually decrease compared to last time if you extend your duration.  The Earned Value People have trouble with that, I don't.

    Back to P%C:  If I have 80 bricks to lay and I lay 20 of them, I claim 25% and I do not care about actual duration, remaining duration.... I am 25% complete. Actual Work, Remaining Duration, and remaing work will drive my schedule and cost performance calculations and tell management if I am on schedule and/or on cost.  Where it gets tricky is when the end product is not so tangible such as a Software Requirements Document ... how will I know when I have 25% of the requirements?  Well, you don't ... but you should have past experience telling you how many hours it took "last time" to get to Peer Review, etc.  From that information you can use historical performance to estimate what 100% shoudl look like in terms of hours and duration... you may say, "Last time, when we were at Peer Review it was 37% of the total hours spent on the document" ... Sounds like your P%C might be 37% at Peer Review.

    As a final point, Project does assume 1 hour of work = 1 hour of progress.  I don't know what else you'd expect it to do.  Only the end user can provide sufficient information to the tool to make it useful.

    I think if you investigate use of Physical%Complete, you will find it much more similar to P6 in the behavior you are expecting, especially when you combine this with remaining work and remaining duration.  My opinion is to avoid draging that status bar around, it causes me headaches as well.  You should also investigate the task types... fixed duration, non-effort driven also helps.... incomplete work will roll forward if you enter actual work < planned work.  Vice versa, if you work 6 hours instead of 4, it reduces the future effort.  That is why you have to babysit both RD and RW.


    If you feel this post answered the question, please vote for it. I am also available here:
    msprojectblog.com
    Thursday, July 21, 2011 3:17 AM
    Moderator
  • Jim,

    I don't like your calculation of % Complete = (Status Date - Actual Start)/(Forecast Finish - Actual Start)

    Surely, it's Actual Duration/Total Duration

    (Status Date - Actual Start does) not always equal Actual Duration.

    A task that started 5 days ago could have been in progress continuously up to the status date and therefore have 5 days of actual duration, but it might also have  any number of actual days fewer than 5, because it got interrupted etc.

    Thursday, July 21, 2011 6:03 AM
  • Subtle, subtle.  Thank you for the clarification.  :)
    If you feel this post answered the question, please vote for it. I am also available here:
    msprojectblog.com
    Friday, July 22, 2011 11:16 PM
    Moderator
  • Hello Chris,

    I am experiencing this Actual Work in the Future issue with Project Server 2010 and am wondering - is there a resolution or re-design for this since your intial post in Oct 2010? I have not been able to find much on the topic  - in fact, your post was the first one to actually confirm that the problem existed outside of our own server. We are using timesheets to update the project schedules and i have several instances where the time entered on the timesheet was changed by the server before the timesheet could be saved, and the project scheduled shows actual time worked in the future. We use timesheets as our source for billing so if there is no remedy out there we have a huge issue. Do you have or know of any updated information on this issue?  I would appreciate it. Thanks.

    Judy


    Judy Washington

    Monday, May 6, 2013 5:39 PM
  • Trevor,

    My company recently implemented Project Server 2010 with timesheets entry. We are using the SEM of entry with the timesheets. Project Server is actually changing what the resource enters on his timesheet before it will save the timesheet. Our timesheets are the data source for billing Time and Materials engagements. What do you suggest is the remedy if the timesheets do not accurately reflect the time entered by the resource? Thanks.

    Judy


    Judy Washington

    Monday, May 6, 2013 5:44 PM
  • Greetings Judy,  my company also has the exact same issue you are having.  We have opened several tickets with Microsoft with one currently open but still have not recieved an answer.  We have SP1 with the April CU on the server and the April CU on client as well.

    Could you tell me if you have solved this issue?  Has anyone found a resolution?

    Bob

    Wednesday, October 23, 2013 3:18 PM