Create Report graph to show accumulated actual % complete vs. accumulated planned % complete over time RRS feed

  • Question

  • Hi!

    In my current project at work I am creating a Report in Microsoft Project 2013, where one of its features is supposed to be a graph that illustrates the accumulated actual % complete of the whole project vs. the accumulated planned % complete over time. However, after extensive googling, I have not been able to find out how to do this.

    Does anyone know how this can be done?

    Thank you in advance!

    P.S. This is my first post on this forum, so please accept my apologies if I am not being clear or break any rules.


    Thursday, January 14, 2016 8:06 PM

All replies

  • Nenrik,

    Welcome to the Project forum.

    What exactly do you mean by "actual % complete"? If you display the Project Summary Task (Format>show/hide group>Project Summary Task, the value in the % Complete will be a weighted average of the whole project. I assume that would be what you mean by "accumulated actual % complete" but I don't know for sure.

    However we need clarification on what you mean by "planned % complete" as there is no built-in metric for that.


    Thursday, January 14, 2016 8:43 PM
  • John is right of course, but I think I know what you mean.

    Where you say "planned % complete", as of when? As of now, today 15th January 2016?

    Where you say "actual % complete", as of when? As of now, today 15th January 2016?

    Where you say "planned", do you mean as it was planned on the date the project started?

    Let's say that the project started on 1st of November 2015, and on that day (or the day before) you had a plan and you have kept it for reference.

    If you have that plan which which pre-dates any progressive status updates and other adjustments and changes made since then, then it has all of your tasks at 0%, so you can set the status date to today and use update project to force MSP to assume that all tasks prior to and up to today actually started and finished as scheduled. All of the scheduled start and finish dates will convert to actual start and finish dates. If there are tasks which are not entirely to the left of the status date and also not entirely to the right of the status date, then they will have an actual start date and all of the scheduled duration from the actual start to the status date will become actual duration.

    All of the actuals will be to the left of the status date and all of the scheduled will be to the right of the status date.

    Whatever, the answer, that's the "planned % complete" for each task and for the project overall from 1st November up to the status date (today).

    The actual % complete is in the current plan file, and comes from the actuals that you have progressively updated each week from when the project started. If you did not update the progress status each week, then you can update the progress of each task now. Make sure all of the actuals will be to the left of the status date and all of the scheduled will be to the right of the status date.

    Any help?

    Thursday, January 14, 2016 10:52 PM
  • Thank you for your quick replies, John and Trevor! Let me try to clarify my terms. I am also relatively new to MS Project, so I may not be using the terms correctly:

    actual % complete = the total completeness of the project as of today (will in fact be the % complete of the Project Summary Task as you mentioned)

    planned % complete = what the total completeness of the project should have been today as if all tasks were to be exactly on schedule

    I would like to graph and follow how these values develop over time, in a Report. Then, at our weekly project updates, I can illustrate that, for instance, the project is one week behind schedule by comparingthe planned % complete vs the actual % complete. (I have made a sketch to try and illustrate how I am imagining these values would look like, but the forum is not letting me post this photo.)

    It is, in fact, the percentage equivalents of Cumulative Actual Work vs Cumulative Work, which can be graphed in a Report.

    Any clue how this could be done?

    Friday, January 15, 2016 7:50 AM
  • henriols,

    Your two definitions are pretty much what I described.

    "planned % complete = what the total completeness of the project should have been today as if all tasks were to be exactly on schedule"

    According to which plan? Or, according to which version? Or, according to the plan of which date? As you develop your plan, every change means that you now have a new plan. The plan that you had five minutes ago is not the same as the plan you have now (call this the current plan). If you just have one version of your plan, then as you make changes to it you are over-writing the plan as you go and you are losing the history of the development of your plan. I save each new version of my plan every day, or even more frequently, so that I have a complete history of its incremental development captured in these incremental versions. When the project actually starts, the development and adjustment and editing continue (because it never stops). Every now and then, save a version.

    Having made that explanation, and answered your original question about how it can be done, and assuming that you do have the "as planned" version of your plan that you wish to refer to, that you wish to compare with your current plan, I must warn you that you are chasing a meaningless comparison, even though "as planned % complete vs current actual % complete" sounds like something meaningful and useful, especially when presented to "management" in a powerpoint presentation. It is not.

    % complete = actual duration/duration, where duration = actual duration + remaining duration.

    If the task had a duration estimated at 10 days and as at the status date you have 6 actual days and 4 remaining days, % complete = 60%. It tells us nothing about whether the task started when it was planned to start. It tells us nothing about the progress of the task, or what the consequences might be or whether any adjustment is necessary or possible. If you decide that 4 days is not going to be enough duration to finish the task and you think it should be 6 days, and you make the adjustment (see the tracking table), then the duration is 12 days and % complete = 50%. Since the % complete is a ratio then any change to the numerator (actual) or denominator (actual + remaining) or both will change the % complete. That's how it works for tasks. For summaries, I will leave it to John to explain how that is calculated , but it is even less meaningful because it is based on the % complete of their tasks. % complete gets rolled up all the way to the project summary task (line 0. You do see line 0?), where it is even less meaningful and not one bit useful.

    I suggest that you drop this idea. I hope this explanation shows why. Mainly, it is a waste of time. You have much more important priorities to address, such as getting your model into a valid critical path method network.

    Any help?

    Friday, January 15, 2016 8:45 AM
  • Henrik,

    You're welcome. Since you are new to Project, let me clarify something. Percent complete is duration based whereas Percent Work complete is effort based. Understand that in Project duration and work are not the same. Duration is simply the span of time during which a task is performed and percent complete tracks the passage of time. On the other hand Work is the estimated amount of effort one or more resources will expend to accomplish the task. If a single resource is assigned to a task full time, then duration and work will be the same, however most of the time, that is not the case. A resource is not assigned full time or multiple resources are assigned.

    I agree with Trevor that comparing "actual % complete" and "planned % complete" is meaningless. It sounds good but it doesn't track parameters that give a valid indication of how the project is performing.

    So far, nothing in this discussion has mentioned baselines. Once a plan is initially developed and looks viable to the stakeholders, a baseline should be set. That will capture the initial plan for later comparison with how the plan unfolds as it is executed. If parts of the plan must be revised due to change in scope, then a new baseline can be set for just those changed tasks or for the whole plan.

    Project has several built-in metrics for measuring performance. For example, there are several variance fields (e.g. Work Variance). I suggest you dig deeper into Project and find out what is already available before you decide you need additional metrics.


    Friday, January 15, 2016 5:19 PM
  • Henrik,

    As John and Trevor have noted, plotting a curve of (duration) percent complete is not generally useful.  That's not what I think you ever intended to do.  Rather, I guess you are looking for "Earned Value" curves ("S-Curves").  Note that these only make sense for a fully resource-loaded (or at least cost-loaded) schedule.

    The three standard curves to include on an earned value chart are the BCWS ("budgeted cost of work scheduled" = the cumulative planned cost, i.e. the planned value curve), BCWP ("budgeted cost of work performed" = the cumulative planned cost of the work that has actually been done, i.e. the earned value curve) , and ACWP ("actual cost of work performed" = the actual cost of the work performed, i.e. the actual cost curve.)  These are the source data for computing Schedule Variance (SV) and Cost Variance (CV).  It is common to normalize these curves to 100% (by dividing by total budgeted cost) - these are the "percent complete" curves I think you are looking for.

    MSP 2010 provides a Visual Reports wizard on the Project ribbon.  You might start there with the Earned Value Over Time Report template.  This image shows the three curves.

    I don't use these reports myself, so I can't help with implementation.  My gut feel is that normalizing to percentages may not be possible inside Project.

    I hope you find this useful. tom

    • Proposed as answer by John - Project Monday, January 18, 2016 3:31 PM
    Monday, January 18, 2016 3:03 PM
  • Tom,

    I agree, I think your answer is a good option for the poster. Trevor and I told him what he shouldn't do but you offered something he could do.


    Monday, January 18, 2016 3:31 PM