Hi Johannes, Of course there were Pele and Maradona among so many others, but be careful with what you had quoted (for me it's a bit dangerous when taken very seriously). Going to the battlefield doesn't always mean that you will go on a suicide mission, but to always find a way to win the battle. And that would sometimes mean to use exactly the strategy of the opponent against them. So for me, real life isn't always "black" or "white" (luckily I'm brown). Sometimes even absolute mathematical computation can be wrong if taken in a different or another perspective: i.e. 1 man plus 1 man equals 2 men (Right?), but if you're looking for 1 man's DNA plus 1 man's DNA, I guess it can never be 2 men's DNA. Best regards

Johannes, Are you still not convinced? Again, I would like to repeat: The belief (that perhaps you have read in almost all reading materials about scheduling), that there should be no "Progress" in a "Baseline Schedule" is for me (I for one), is very "WRONG". Otherwise, you can always opt to side with Zoltan. Zoltan, I'm sincerely sorry. I've never meant what I said personally. Please reply now, your knowledge in P6 is for me, amazing (just need to be polished a little bit).

Johannes, What I'm saying is that there's no real progress in an original baseline schedule but an imaginary one (as you had originally wished to happen or exactly as planned) that you must compare to your current or working schedule and that would become the basis for calculating actual performance, to see if you are gaining profits or not (at a certain time) i.e. Planned vs. Actual (you may ask some contractors whether or not this is true). The fact is, or in real life, your current, working, or Updated schedule today can possibly become your new baseline schedule tomorrow (and it is always a possibility). So there would be real progress now in your new baseline schedule (at least all in the Left of the Data Date). Actual data cannot be changed. So you will work out your new schedule (baseline and current) starting from the new data date.

I forgot to mention that: To assume that there is no progress in a Baseline Schedule is WRONG. The first time you develop a baseline schedule, it is your wish that the works will turn out exactly as planned at a certain time. So your wish itself is an imaginary progress that has corresponding mathematical value in your baseline schedule. During the course of the project, you may come to realize that your original baseline schedule is not anymore feasible, so a new baseline would be necessary. In this time that it is necessary to consider real or actual progress (or performance) in your new baseline schedule in order to predict the outcome of the future. You can create as many baseline schedules as you wish for as long as it is agreed and approved by the stakeholders. After all or at the end of the day your wish (baseline schedule) must be compared to your actual performance.

that makes no sense AT ALL you can use progress over ride in a baseline all you want to it will have NO EFFECT on the schedule since there is NO PROGRESS TO OVERRIDE.

I already gve you the technical reason but you refuse to accept it. 

As far as experience goes I have been doing this since the days of key punhc cards using main frames for scheduling.

With 40 years of experience under my belt I believe that I  have a wealth of knowledge and experience. I also believe that the AACE Best Practices does not endorse Progress over ride. I am also very sure that if you go to court for a schedule claim and it turns out that you used progress override that the scheduel will be declared invalid and that yuo will lose the delay claim. 

Maybe I am so adament about it is that I know the correct way to schedule a construction project. 

If you know anything about scheduling you know that prior to the pdm method there was the adm method. This method nor did any of the earlier schedulgin programs even have a Progress Over ride function. In my opnion it was added for project taliored towards IT projects where HARD realtionships do not matter as they do in construction

I too rest my case on you and of course you too are entitled to your own opinion.

Best of luck with your scheduling in the future.

I cannot see any technical or scientific reason that makes you so adamant, but perhaps just being too inexperienced and maybe exposed to a very limited extent of knowledge, so I may rest my case on you. Of course you will always be entitled to your very own opinion.

Zoltan, please read again the link and understand it. It is not an error caused by progress override but an originally wrong logic applied with actual progress. Of course when you first create a schedule, you use retained logic as there would be no actual data to consider. Once your project progresses, of course you have to consider actual data as it is a fact that you cannot neglect or deny. That's why there is another setting "actual dates", right? The use of actual dates is for completed activities, while progress override is for in-progress activities. There were lots of reasons that causes negative float and it is not necessarily caused by your calculation settings. Again, actual data is a fact that you cannot deny. Logics are only theory until realized. I hope it's clear now, otherwise, please don't hesitate to ask questions.

The Theory isn't WRONG! But your application is WRONG as you did it intentionally, in other words, you murdered the theory. Theory per se can be twisted or manipulated in any way you want, but real life situation cannot be, otherwise, it will be obvious. The theory of "progress override" has good purpose, hence, you must use for that alone. On the other hand, the theory of "Retained Logic" can be twisted too, and make it appear to be WRONG. So why don't you illustrate a twisted version of retained logic too? Or maybe you still don't understand what I'm saying or my previous posts? Sorry, English is not my first language.

Amusing few posts there.. +1 to the point Zoltan made

we will have to agree to disagree my example is corrrect the example shows out of sequnce work becasue they got a jump on the drywall.

You are 100% correct when you say that  "it never happens in real construction". BECASUE IT CANT IT IS PHYSICALLY IMPOSSIBLE. 

My example stands and I will stand by it 100% 

no one is saying not to correct the out of sequence logic but to say that it is ok to fix this simply by changing the calculation setting is WRONG as in my example you can see that using progress over ride causes incorrect float values as well as permittign the drywall to be completed prior to the studs being installed wihwhich is physically impossible.

ALL of the scheduling specifications specifically state that retained logic must be used. There is an excellent reason for this which I have already given and example of.

progress over-ride does as it implies it over rides the logic. Using this can cause incorrect float values as well as permitting hard logic be ignored. For example using this will permit the drywall to finish before the studs are installed which is physcially impossible. 

For the construction industry I donot ever see a use for it maybe in be IT sector. 

Best explanation for retained logic and progress override ( Download PDF free also)

Please refer to the following link; http://www.warnercon.com/articles/Article%209%20-%20Handling%20Out-of-Sequence%20Progress.pdf

Not everyone is in agreement to which option is best, a majority favors retained logic contrary to the author of the reference. But in order to keep uniformity one of the two must be specified.

• I agree with the author that progress override can make it easier to fix the logic while retained logic tends to highlight the out-of-sequence activities.
• I do not agree with the author that progress override is a better specification, perhaps retained logic as a specification makes more sense because it tends to highlight the out-of-sequence occurrence forcing the lazy scheduler to adjust logic and making it obvious for the unqualified reviewer.
• I do not agree with the author that not all out-of-sequence logic shall not be required to be removed. I have a higher standard of quality, I believe in specifications that demand no out-of-sequence progress because this will retain the actual schedule logic intent to better reflect reality. Even when the specifications do not require all out-of-sequence logic be corrected I do it on my jobs. Fix it, make it 100% "accurate". Anyway we are usually required to use retained logic, and because retained logic splits the out-of-sequence activity and we schedule for continuous activities unless there is a lack of resources the output is never out plan, we have to fix it.

A contractor that believes out-of-sequence will not be scrutinized is a fool, it is the most obvious of all issues.

Maybe removing out-of-sequence logic takes some time but I do not agree this is an excuse to be sloppy and lower the standard. Updating a large job requires more time than a smaller job and because of the complex interrelationships most probably in a larger proportion.

I have seen sloppiness of some contractors with regard to updating out-of-sequence logic but also very frequently when an activity is interrupted several times they do not record the interruptions nor the production of each work segment. The time-production relation is a requirement to substantiate the effect of disruption on productivity loss. Some contractors see how the productivity is reduced and complain but forget the burden of proof is on their side and wait for too late to get the information when a substantial is already lost forever. Very frequently they come asking for help, when it is somewhat late. Then they realize how important doing the right thing on time is.

Documentation, Documentation, Documentation

After reading this entire post, I am resurrecting it as I recently found out that a division of Los Angeles County is about to release a revised scheduling specification that requires the use of Progress Override.

For the record I have been working as a project controls specialist for the last 21 years in both the public (City, County, State, and Federal) and private sectors.

The only time I have ever used Progress Override was in the private sector to circumvent delays and provide a more politically acceptable forecast that everyone in the room knew was not accurate.

I would never do this on a Public sector job as it can lead to being slapped with a false claim accusation that has legal rammifications.

The best document I have read that explains how Primavera handles progress override vs. retained logic is here:  http://www.htcprojectcontrols.com/SB002.pdf

Progress Override as applied by Primavera violates logic ties and in my opinion for that reason is not as accurate as retained logic.

There is no such thing as a project that does not have out of sequence issues.  People in the field do what they have to, to be productive, in the face of owners constantly interfering with the project.

I am happy to fix all out of sequence issues, or most of them, for my customers, however very few are willing to pay for it when specifications do not clearly indicate it is a requirement.  This is not to say we don't address it at all, only that we do only what is really required and allow the project plan to play out.

In my 21 years of work, rarely has it ever been an issue.  I have used the above linked document many times to make my point clear to owner reps that try to make the schedule into it's own project.  Also to make clear that there is a difference between a requirement and a request when it comes to schedule comments.  Bottom line is that it is the Contractor's means and methods that rule the day and not unspecified requests by the owner.

In my opinion, the use of Progress Override is an attempt to try and shoot down delay claims by contractor's, by organizations that lack the skill to manage projects without being part of the problem.

Scheduling does not and should not require allot of work to maintain in order to provide valuable information to a project team.  Granted, this scales with the size of a project and schedulers cannot allow themselves to become captured by details that do not truly add value.
 

I do not understand why Primavera has this option called "Progress Override" It does not make sense..it basically defies logic.(LOL) The best practice is to correct the logic first as it actually occurred and then update it. Actually, there are a lot of activities scheduled with a FS relationship, when in reality, they can actually have a SS relationship. There are also cases where you need to work around to mitigate delays and this needs to be reflected in your working programme so as to know the impact or the consequences of such change. In any case, I agree with Stephen that the PM/Planner should be consulted or notified first before proceeding with any change in sequence or logic.

Cheers

Tamara,

If the idea is rejected, keep the second schedule for yourself and for managing the job. I do not believe it will be successful because in my experience I have not found the smart Owner Rep. However, you still have to try it in order to claim you have been denied the opportunity. Under these conditions, all you can do is submit him the schedule under the "contract rules" or its interpretation by the reviewer and make it clear, within the narrative, that it does not represent actual plans because the reviewer prevents you to present such schedule.

Whenever there is a wrong evaluation or decision, you shall immediately inform about your findings for the record. If you do not keep a schedule that represents true job conditions how are you to substantiate your findings? How are you to manage your job? Are you to use just his wrong plan and the rest play it by ear? Here you will have the opportunity to expose how wrong it is to use a schedule that do not represent the actual conditions of the job.

Perhaps good specifications should address directly the issue and define what a Contractual Baseline or it revisions mean and what an Update Schedule shall disclose, maybe actual plans although not contract binding any of the parties in any way, more like an informative submittal.

Devaux strategy to look for a transparent disclosure is correct, then if no other option keep for yourself the second schedule. What else can you do?

Best Regards,
Rafael

Tamara, what Rafael said. Any time that a project is being done on the basis of the contract, there should be 2 schedules: what I would term the baseline schedule, and the working schedule. The only way to meet contractul obligations is to work to a working plan which is more aggressive -- otherwise you will miss the contractual milestones, and go over budget, every time.

This is often hard for DOD contractors to understand -- I often get the complaint: "But that means we will have to keep two schedules!" Guess what? When our works slips beyond our contractual schedule, we’re maintaining two schedules anyway -- only now the working schedule is later than our contractual schedule! And, as Rafael points out, there are techniques that you can use within the software that will allow you to update both schedules without much effort.

There are some DOD people who are very smart and understand project management. But most don’t. The DOD contracts people will often try to make the contractor do totally ridiculous things. They don’t know much about project management, any more than the contractor’s contracts people do (why is it that these people never get trained in critical path method??). As Rafael says, if they see schedule or cost reserve in the program plan, they are likely to say to get rid of it. In such a situation, I try to persuade them that in order to meet their needs, the contractor has to work to more aggressive parameters.

Sometimes this is persuasive, and sometimes it’s not. I like to keep things on a project as visible as possible -- but in unreasonable situations, there is often no reasonable solution. Sometimes all you can do is have a very large-duration/big-budget item at the end of your project, called "Test and Integrate". And you’re likely to need all that time and budget!

Finally, from the opening comment in your post, I’m not sure if you think I’m a proponent of Retained Logic -- I absolutely am not! If the logic is incorrect, or can be improved, I am all for changing it. I am simply opposed to engineers changing the logic and doing out-of-sequence work WITHOUT first running it by the PM/planner. Often there are factors that the engineer is unaware of, and the change may cause huge problems. Just as with scope changes, logic changes should be made only after analysis.

If the engineer has a good idea to change the sequence, I’m all for it! But then let’s also change the plan to reflect the new reality.

You my be aware that, on DoD work, out-of-sequence work is often done simply to "game" the SPI -- and that’s just fraud! And that’s why I’d come done like a ton of bricks on anyone doing OOS work without first running it by the PM/scheduler -- I have no desire ever to see the interior of Leavenworth!

Fraternally in project management,

Steve the Bajan

Stephen Devaux
"Hi, Andy. Not surprisingly, lots of US DoD projects!"

Oh, that explains it.

I’ve got a DoD project running right now, where the Corps requires us to use Retained Logic (fine), but will not allow us to change logic when project conditions change significantly (not fine). Therefore, the schedule inaccurately shows that we have -70 dats tf, and it can no longer be used as a tool to manage work.

Wilfredo,

If the logic, progress & data date are all set to correctly reflect what has, is and will occur on the project, then you will see no difference between retained logic and progress overide.

Perhaps I have been lucky, but in virtually every job I have had, the main job of the schedule has been to help the project team deliver the project, which is done by having an accurate schedule, which is more likely with retained logic.

I wouldn’t last long in a job where I was required to lie to help the company get paid.

BWA HA HA,

you guys must have live i a close world where you can hope to do what you are supposed to do.

The basic problems in progress overide or retained logic is

the strong presence of your commercial manager or contract manager in your project team.

This bimbo dictate the way planning ctivities, including the use of progress override or retained logic, should be presented to optimize profit but never attain professionalism in planning engineer.

So before you decide on a case to case or project to project basis, check first your company or project team leaning:

Is there a strong commercialization of the project by the company or
the company treat each department in a professional way.

If there is a strong presence of commercial manager or contract manager, just play their game and dream of some sort of neverland like peter pan,

where you can practice the true planning engineer profession.

GB, PTL, & TY.
Scarlett

Wilfredo,
It seems as there are many views and things to consider.

For me at the moment the statement that has made the loudest noise was from Gary. I believe that his statement “Even if it’s not a problem, understanding why it occurs is still a good learning experience which will help you build better schedules in the future” is something we should all strive to achieve.

Understanding why and building lessons learnt database which includes such things as schedule analysis against its original baseline is a very powerful thing.

The use of either Progress override or retained logic, are merely tools, as with all things in a real moving world, you need to be careful where you put your faith and trust. Steve enjoys the sanctity of firearms and shovels it seems. :-)

Rafael is right, using either option still leave the issue un-resolved; you need to know the why. At the end of the day it’s about analysis, knowledge of what ‘should’ and ‘IS’ happening, having the skills and knowledge to not only understand the issue but be able to explain it to people who do there scheduling on the back of an envelop, or heaven forbid as colored boxes in MS excel. Don’t laugh – I’ve seen an EPCM schedule for a minerals job in excel using colors.

My latest schedule is based around contractual deliverables, and has a good number of constraints throughout to hold the activities where we think they’ll start. I don’t have the opportunity to use much logic as the requirement is to analyze the schedule performance based solely on the projected end date of the engineering deliverables assigned to each ‘contractual workpackage’.
Is it right?
Am I happy about this?
Only time will tell.

They wanted a new methodology based on a new engineering deliverable document progress measurement tool they have. This is the first go. I think I’ve got it right for what they want, but no amount of progress override or retained logic will help me because there isn’t going to be a critical path.

Murphy starts on the job next week and I guess he’ll muck things up for sure.

Andy

"Can I have a list of the projects you work on?
I’m adverse to gunfire so I’ll steer clear of those"

Hi, Andy. Not surprisingly, lots of US DoD projects!

Steve

Stephen,
Can I have a list of the projects you work on?
I’m adverse to gunfire so I’ll steer clear of those.

I know a bloke with a time machine - he may loan it for you to go back in time without using progress override too.

LOL

Andy

Guys, I don’t think it is as simple as saying just use progress override as the activities start out of sequence.

You should really firstly consider why those activities have started out of sequence. Is it because someone accidently ticked the wrong box somewhere? Is it real - did work actually commence and why, early access, job became critical in someones eyes, seemed like a good thing to do, needed to give the work experience kid something to do???

The ramifications of doing the wrong thing with respect to these scheduling options can be substantial. more often the impact will be negligable, but we all know that as soon as you take things for granted, it goes pear shaped real quick. (Curse you Murphys Law!!!!!)

I have often found that progress override gives me an unrealistic short term resource profile if left unchecked. Where possible I like to understand the reasons why the activity has started at the worng time. I can say more often than not it was simply because the people who gave you the logic did so without much care or thought, thinking it was a "box ticking exercise" just to get the planner off their back.

When using retained logic I feel that more often than not you get a more realistic initial look at the end date of the schedule. If the team don’t like the numbers, then its back on them to understand what it is they are actually doing. Fix any logic, or find more bodies to throw at the job.

Anyway, I guess it’s like having $5 each way on the outsider everytime we status a project schedule, sometimes it pays off and other times it dosen’t.
So I just check each answer and present the options, hey, we’re not paid to make the decisions, just provide the data so the PM can.

Andy