Difference in Orginal duration

Weird.

Generally I no longer have this issue as the software I use do not perform in such a weird way but at times I must scope with it when interpreting schedules developed by others using software such as SureTrak.

Rafael,

That's happening to P6 too.

We need from Arun a more clear view of his problem.

Regards,

Raymund,

I understand the rol-up might be inconsistent because the duration of the WBS is not equal to the sum of the duration in hours of the activities but a function of its start and finish dates in combination with its own calendar, computed as if an individual activity, but no a matter of what value it is, the original duration value at every WBS shall remain the same of whatever the computation was at the baseline. Arun said the issue was in the difference as the result of the updates, not an issue that was observed at the baseline.

"... while updating the program the original durations in different WBS Levels  are different..."

The strange behavior of some software in computing durations is not exclusive at the activity level but also at the WBS level. The described weird computations I know happen in SureTrak and believe in P3 as well as in MSP, not sure about P6.

Just take a look at the following figure, depending on how the calendars are defined the weird durations can be observed at the WBS level in some software applications.

If you want to make the WBS value for duration to be the sum of the individual activity durations in hours this is another issue you must solve using formulas and setting up the appropriate roll-up, but this is another issue. Arun mentioned the issue is about changed original durations after updates, a change observed at all WBS levels. I believe only he can clarify if the issue is about the difference between updates or that he does not understand how his software computes the WBS value.

Best regards,

Rafael

wo, uo, uo... she is a lady

Have some fun, today, just before Irene the tropical banana tree knocking down storm arrives, I will be having lunch with some friends from Canada that came to the Island for their Caribbean cruise on peak hurricane season.

Rafael,

Based on this post of Arum....

"I am facing a problem in  P7. I prepared base program and updated.while updating the program the orginal durations in 

different WBS Levels  are different."

 As I understood from the original post by Arun… Original durations at the WBS level are inconsistent with the durations on the activity levels.

This happens when another calendar other than the default is assigned to some activities.

Regards,

Raymund,

What you mean, that the calendar was changed during the updates, after the baseline?

Does P6 allows for original duration be changed, if so it is not the original but a revised duration? If P6 allows for the original duration be changed then a workaround might be displaying original duration from the baseline or using a user defined field to look for the true original duration.

Best regards,

Rafael

HI,

YOU MAY BE USING A CALENDAR OTHER THAN THE DEFAULT.

Hope this will help.

Just do the math from 27-jul-10 AM to 17-jan-12 PM there are 540 calendar days. I am curious to know which calendar yields a difference between two dates of more than the calendar days in between the two dates.

It is a Bug of the most aberrant type, very dumb, common in US CPM software. At times makes me wonder where our best minds are.

It would be interesting to know if Asta copycatted this anomaly.

Take a look at the following Gantt, Activity 5 is after DD and is not a summary bar but a typical duration activity type. It displays a duration of 200 days from 03jan11 to 11mar11. This mother of all bugs is real, and has nothing to do with summary or WBS bars.

If I need Activity 5 (code 2040) to finish 3 months after it started, say exactly on 3apr11 can you guess the duration? Well SureTrak says it must be 270 days. If you move close to the speed of light Einstein said time expands, but here it is contracting, between two dates more time fits than their relative time difference moving at zero relative speeds. Perhaps the developer figured out the unifying theory. Got to be related to how electricity moves within your computer chip.

It is very simple, no rocket science, in between Jan-3-2011 and Apr-3-2011 there are 67 calendar days, can only fit up to 67ea 24 hours workdays, can only fit up to 67ea 8 hours workdays and up to 67ea 16 hours work days. But 200 workdays is a crime against nature.

THIS IS NOT EXCLUSIVE OF A SINGLE SOFTWARE - MANY HAVE IT, THOUGH NOT ALL.

It's not unusual to have fun with anyone

Whoa-oh-oh-oh-oh

Got another way to fool the forensic analyst, maybe Mike does not know about this one. No wonder the 4 gurus could not follow the logc, they did not figure it out the sofware was flawed.

hi arun

are you having different calendars inside the project?

check your global calendar time/hour setting

It is older than P6, it comes from the days of P3 and SureTrak and believe MSP. I do not know if P6 have this behavior. I am posting it as a possibility for those who have P6 to verify themselves.

I included another version of the same activity just to add to the confusion, in these software if you change activity calendar after creating the activity for the first time then everything get messed-up.

As you can see activity 1 code 2000 start and finishes the same dates as Activity 2 code 2010 and displays the correct OD and RD as I never changed the calendar.

If you got the Alzheimer never change calendars.

You have no idea how disappointed I was at the behavior of these software, going over and over the same horrors. So bad that their dysfunctional behavior is not limited to resource loading and the concept of work and productivity but also to the most basic computations, as if rocket science.

I learned this the hard way, after costly errors to the contractor. I believe software vendors should be required to disclose BUGS in new versions if the Bug was known and not solved, the same way packs of cigarettes are required to disclose the danger of smoking.

Hi Arun Vasanth & Rafael Davila

|This is another flaw from P6

Maybe at some time after creating some activities you changed the calendar. Some software such as SureTrak have similar issues. Once you define your activities if you change calendar it keeps displayed OD and RD as if computed using the original calendar but the actual value used for date determinations are computed using the new calendar. For some computations if forgets you changed calendars and use the wrong calendar, for others use the correct one.

This issue is very confusing I named it the CPM Alzheimer.

Try modeling the following activity first with a 7 days per week calendars. Once again create the same activity with the same 7 days per week calendar and change it to a 5 days per week calendar. If the bars and date change but the displayed OD and RD are wrong then your software got the CPM Alzheimer disease. Like Alzheimer it has no cure, only after the activity is dead it will be over. Like Alzheimer it is difficult to detect with certainty, perhaps even more as with Alzheimer an autopsy can tell here no forensic will. It is common on those days, I believe even MSP got it.

Not all software got the Alzheimer.