if you missed part 1 of schedule % complete in oracle primavera, go back now and have a read through. then come back here.
the proper setup : baselined and cost-loaded
now let’s see how schedule % complete works in action on a sample primavera p6 plan.
since schedule % complete is based on both project baseline fields and earned value cost fields, to calculate it properly, your schedule should:
- be cost-loaded at the activity-level
- have a project baseline set
examine the sample plan below. this plan has four wbs elements in two levels and seven activities. activities have sample durations and relationships and you can see the current schedule in the gantt chart. each activity has a resource assignment and that’s why we have costs in the plan. some activities have uniform resource curves, while others use at-start, at-finish or bell-shaped resource curves.
the project baseline is maintained and assigned. the baseline schedule is shown by the yellow bars in gantt chart. the current schedule and the baseline are the same now.
examining schedule % complete for activities
i will reschedule the plan for the second day, moving the data date forward 1 day.
there are no actuals entered, but as we saw in part 1, schedule % complete has nothing to do with the current schedule or actual data. the schedule % complete column shows the current values; for example, take a look at a4:
the data date has passed half of the baseline schedule of a4, which would be the schedule % complete of 50%.
sometimes you have nonworking days in the schedule; in this cases, those days would not be counted in passed and total baseline days (as usual).
schedule % complete for wbs
let’s examine wbs e-2.
wbs e-2 has the following values:
- pv (planned value cost column) = $240
- bac (bl project total cost column) = $400
the wbs schedule % complete is calculated as pv / bac = $240 / $400, or 60%.
how bac and pv are calculated for wbs?
1. bac – budget at completion
bac for the wbs element e2 is the sum of the a6 and a7 bacs. think of this as the sum of the total cost for each activity (see diagram above) but taken from the project baseline.
2. pv – planned value
planned value (pv) is bit trickier as it related to how your schedule is cost-loaded in a time-phased manner.
the activity usage spreadsheet, shown in bottom half of the screen below, is handy for analysing planned value for activities.
the bottom layout is set to show timephased values of the cumulative planned value costs using the activity usage spreadsheet. why use the cumulative planned value cost field? because it’s essentially a running total. with that in mind, in this view we can quickly see a running total pv for the wbs at any day in the project.
planned value….elaborated
planned value taked into account resource curves. let’s explore activity a6.
a6 has a uniform curve and it has only two working days, $80 planned for each one. $80 for the first day, and the cumulative value remains 80$ for the next two nonworking days, then increases to $160 in the last day.
activitya7 has an “at start” resource curve assigned. all of a7’s planned cost will be loaded to the first day and the cumulative value of the next days would be the same.
no matter how the activity planned values are distributed over time, the wbs’s planned values are the total of the activities’ planned values.
the data date in the previous sample was the second day of the project and pv of the last wbs element is 240$ in that day. if we change the data date to the sixth day, its pv would be $320. the following figure shows the values with the data date set to day six of the project.
when things don’t add up – a scenario using resource curves
before wrapping up, let’s look at a tricky scenario; i made some changes and re-baselined the schedule. check the values for wbs e.1.1.
as you see, wbs e.1.1 and all of her underlying activities have costs. two activities have schedule % complete values that are greater than zero and the wbs element’s value is still zero. why?
i believe you can say; when schedule % complete of the wbs element is zero, you should expect that the pv is also zero. how is it possible for the pv to be zero when data date has passed half of the baseline duration? the answer is simple: the activity costs are not uniform…. because of resource curves.
all of these three activities’ costs have “at finish” curve. the following figure is focused on the a2:
many planners use resource curves in their schedules to properly distribute labor hours and costs across an activity’s duration. but keep in mind that resource curves can cause scenarios like this one to confuse and puzzle you, if you are calculating and finding strange values for schedule % complete. here’s another reason to know your schedule intimately.
wrap up
to conclude, you should never expect wbs element’s schedule % complete to be a rollup of the underlying activities’ schedule % complete, because they are calculated in two completely different ways.
that’s the whole story of the schedule % complete. in every control period, you will enter actual data (actual start, actual finish, and at least one element related to the progress of the in-progress activities) and receive planned and actual progress. planned progress is to be read from schedule % complete as percentage values or planned value cost as monetary values (based on your preference). planned progress of the whole project is read from schedule % complete of the project row (lowest level of eps or highest level of wbs). it’s sometimes necessary to also report on planned progress of the first two or three levels of wbs, which can be done by reading the schedule % complete of the appropriate wbs elements. you might not find it suitable to read the planned progress of the activities from schedule % complete, because it’s not based on their assignment curves, unless your method of calculating the actual progress is not using the assignment curves too.
