Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Retained Logic or Progress Override

53 replies [Last post]
Wilfredo Barbacena
User offline. Last seen 2 years 45 weeks ago. Offline
Joined: 13 May 2009
Posts: 30
Hi,

When do we need P3 to calculate the schedule update in retained logic or progress override? Is it by the project condition or requirements or it does not bother at all...

Thanks for the any information...

Replies

Zoltan Palffy
User offline. Last seen 7 hours 39 min ago. Offline
Joined: 13 Jul 2009
Posts: 2078

I have given my POLISHED guideance here take away what you want I am done here. 

Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
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 Vandenberg
User offline. Last seen 1 hour 15 min ago. Offline

Hi Anoon

Johan Cruyff isn’t only the best football player the world had ever seen until Lionel Messi, he’s also a visionary, philosopher and insufferable know-it-all. Luckily, the Amsterdammer never kept his wisdom for himself: everyone in the Netherlands can reproduce at least one of many classic Johan Cruyff quotes. We examined 14 of them and came up with some shocking conclusions…

 “It’s better to go down with your own vision than with someone else’s.”

The bottom line is: if you have a vision of your own, stick to it.

Regards Johannes

Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
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 Vandenberg
User offline. Last seen 1 hour 15 min ago. Offline

Humm…

Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
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.
Johannes Vandenberg
User offline. Last seen 1 hour 15 min ago. Offline

Hi Anoon

I forgot to mention that: To assume that there is no progress in a Baseline Schedule is WRONG

There should be no progress on the original baseline schedule. When you have maintained and assigned the baseline to the project this will remain unchanged. This is the project baseline. This can be in time, scope en for the costs. So as all the other knowledge area's.

When you come to the controlling phase of the project and you update the schedule than this schedule becomes the  'current schedule'. It is like sliding doors. The original is in the background en de current schedule is in the foreground and that is what see unless you display the baseline as well.

If the project requires a revised baseline then you again maintain a new baseline and that becomes a second baseline. Now you can assign the original and the new baseline.

Regard Johannes  

Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
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.
Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
Oh, sorry for any inconvenience. I don't know that you cannot understand simple English as well, but that's the only other language that I know. Again, I'm very sorry.
Zoltan Palffy
User offline. Last seen 7 hours 39 min ago. Offline
Joined: 13 Jul 2009
Posts: 2078

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.

Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
Again, in my opinion, you were just constrained to a "Target or Baseline Schedule". I would like to reiterate that I agree with you to use only "Retained Logic" for "Baseline Schedules" (I believe this is self-explanatory for skilled and experienced schedulers). By the way, I don't read books or any recommended practices or references about scheduling to be honest. If I happened to read maybe, then that's just out of curiosity or perhaps entertainment, but for me, it's more entertaining and educational here in PP, and the best thing is: it is Free! (but I might send you the bills later). Nevertheless, going back to "Progress Override", the term itself will tell you that it will only apply to an actual situation that supersedes a plan (or an imaginary logic that was maybe wrong or perhaps not practical to be followed). I believe that's a straightforward definition of that. Or in other words, to rectify a wrong plan or logic in the real or actual situation (did you happened to read my explanation in any references? Otherwise, I shall put quotation marks). Now, if you insist on using "retained logic" for an already progressed schedule that have much OOS (out of sequence) activities, then of course the results would be wrong. This is where you use "progress override" to determine real progress (in terms of actual percentage), and then go back to trace the mistakes. Of course it is one of the tools to be used in rectifying the schedule. Otherwise, or if you continue to stick with "retained logic" without rectifying the mistakes (as where you personally stand and insist), then I cannot do anything with that anymore. I'll leave that to you, sorry.
Zoltan Palffy
User offline. Last seen 7 hours 39 min ago. Offline
Joined: 13 Jul 2009
Posts: 2078

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.

Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
Oh I'm sorry, I was thinking perhaps you were too focused on an un-progressed baseline schedule. Of course "Retained Logic" is your only option for creating and maintaining a baseline schedule. However, for a live, dynamic and or working schedule, it is necessary to be flexible in order to capture the real situation, therefore, you were given another option of "Progress Override". As in real construction, being a planner or scheduler doesn't mean that you know everything. In fact, planners or schedulers were usually the most ridiculed person on the grounds or on site (again, apologies). Experienced builders do not need any software to plan their works (believe me, it's all in their heads, even when having nightmares). Capturing true actual progress cannot be achieved when using or insisting on "retained logic" that was not actually followed.
Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
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 Palffy
User offline. Last seen 7 hours 39 min ago. Offline
Joined: 13 Jul 2009
Posts: 2078

yuo can use what you want but if you submitted a schedule to me with progress over ride it would be rejected for the reasons that I listed.

Good luck  

Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
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.
Zoltan Palffy
User offline. Last seen 7 hours 39 min ago. Offline
Joined: 13 Jul 2009
Posts: 2078

1. my example is spot on

2. Why do you think that almost all scheduling specfications prohibit using progress over ride ?

3. Please see this post here it is another example of an error caused by progress over ride

http://www.planningplanet.com/forums/planning-scheduling-programming-discussion/582149/primavera-v84-out-bounds-error

As everything in this world you have a choice. My choice is NOT to use progress  over ride for some of the reasons listed above.

We had an instance where the contractor had some negative float and on the next update without any revisions just applying progress he showed positive float. After reviewing the schedule it was determined that this was due to changing how the float was being calculated which was the use of progress over ride. 

Everyone agreeed that this was not the correct option and to change the setting back to retained logic. The proof is in the pudding. 

 

 

Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
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.
Zoltan Palffy
User offline. Last seen 7 hours 39 min ago. Offline
Joined: 13 Jul 2009
Posts: 2078

the example is not wrong it is the EXACT same schedule. The ONLY difference between the 2 is using retained logic vs progress over ride. Here is is again the exact same schedule

here are the 3 schedules the

planned no progress, progress with retained logic and progress with progress override

both progressed schedules are the same the only difference is the calculation which progress over ride is incorrect as you can plainly see the drywall finishing BEFORE the studs. Using retained logic this does not happen and is the correct way which proves why using progress override should not be used.

6332
override.jpg

The Hanging of the drywall cant be done before the studs it does exactly as it says it OVERRIDES logic this is unacceptable.

Safwan H.
User offline. Last seen 1 week 10 hours ago. Offline
Joined: 13 Jul 2015
Posts: 10
Groups: None
Amusing few posts there.. +1 to the point Zoltan made
Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
As a show of courtesy to the readers, I for one would not give an example that I knew beforehand that it is wrong and can never happen in reality. Theory (right or wrong), can be easily explained and may perhaps mislead others once misunderstood. For the sake of a sensible discussion, Yes, I agree to disagree with you. However, this is an open forum which I believe the objective is to seek for ideal or perhaps the best answers to whatever questions that may arise. Again yes, I agree that you are WRONG, and thank you for admitting your error, but don't worry, no one is perfect anyway.
Zoltan Palffy
User offline. Last seen 7 hours 39 min ago. Offline
Joined: 13 Jul 2009
Posts: 2078

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% 

Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
Sorry but the example that you had illustrated and considered excellent is WRONG, and it never happens in real construction. It's very easy to illustrate a wrong example and make it appear to be reasonable. However, real life is different, and as I've said, builders or people on the grounds (which may not even understand how to use any software) are for me, the best Planners. So you cannot expect that they will follow exactly the logics as you had specified in your schedule all the time, but it never means that people on the grounds will do the works wrongly. They may just be correcting the wrong schedule that you had issued. Now, if you will not allow the experienced builders to correct your schedule (as you insist on your logics as planned), then that would be a different story. Again, as I've said in my previous post, if you had created a schedule that was based from a mandatory "method statement" (as there would be no other way to execute the works scientifically), then of course "Retained Logic" is the only option. Otherwise, use "Progress Override", as in real life, you can never avoid the occurrence of Out-of-Sequence activities (Nobody is Perfect).
Zoltan Palffy
User offline. Last seen 7 hours 39 min ago. Offline
Joined: 13 Jul 2009
Posts: 2078

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.

Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
In real life construction, the builder on site knows much better the ins-and-outs of construction than the so-called planner/scheduler sitting in the office and maybe a master of the software. As a consequence, the software generated schedule were not usually followed, therefore the occurrence of out-of-sequence activities. In any case, overriding logic as planned doesn't mean you are intentionally committing an error, but may really mean correcting an existing schedule that is in error. Further, overriding logic through actual progress do not show criticality in the past, but will predict a more accurate criticality in the future (as evidenced by actual performance of the past). Now, if you insist on keeping logic that was overridden already by actual progress, then to me, that is an error intentionally done, while you have the opportunity to correct it using "progress override".
Zoltan Palffy
User offline. Last seen 7 hours 39 min ago. Offline
Joined: 13 Jul 2009
Posts: 2078

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. 

6297
zccapture.jpg

Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
After reading thru the comments, I found out that I was the first to comment and I guess this wasn't cleared-out. Well, a logic-driven plan remains a plan until realized. During the realization stage that you found out that what you have firstly thought as not possible becomes possible, so why insist on keeping "retained logic" when you had actually done the works overriding logic? And I guess there's no perfect plan after all, so it is just natural to have OOS activities. Of course you have to correct them as you go along the process. The occurrence of out-of-sequence activities doesn't mean that the works where done wrong, but simply did not follow exactly the logic or sequence as scheduled or planned. If you had created a specific "method statement" for doing the works that need to be followed word-for-word or step-by-step, then you need to insist on retained logic, in which case, the works are obviously wrong, should there be out of sequence activities. Otherwise, why not use progress override?
Ali Osama
User offline. Last seen 1 day 5 hours ago. Offline
Joined: 19 Dec 2017
Posts: 27
Groups: None

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

https://bibloteka.com/retained-logic-vs-progress-override/

Khuong Do
User offline. Last seen 3 weeks 3 days ago. Offline
Joined: 21 Feb 2010
Posts: 112
Groups: None

Hi,

I wrote an article explaining How does Retained Logic, Progress Override and Actual Dates in Scheduling Options work?

Kindly read it here : https://doduykhuong.wordpress.com/2016/06/08/how-does-retained-logic-progress-override-and-actual-dates-in-scheduling-options-work/

Rafael Davila
User offline. Last seen 2 hours 49 min ago. Offline
Joined: 1 Mar 2004
Posts: 4620

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

Erik Lange
User offline. Last seen 6 years 18 weeks ago. Offline
Joined: 6 Oct 2011
Posts: 4
Groups: None

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.

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. 

 

Being a project controls specialist as well for the past 13 years and having worked on numerous large public works projects, I can think I understand why they would specify the use of Progress Override. In my experience, contractors are loathe to update the schedule properly taking into account any out-of-sequence work as it rarely provides them any benefit. This also tends to benefit their use of the schedule as a claims tool showing delays as out-of-sequence work is not taken into account.

By specifying Progress Override, it would seem the contractor is forced to be more diligent in properly updating the schedule if they want to submit a claim. With regard to the false claim accusation, are you indicating that it would be the contractor or owner would be slapped with a false claim? Can you elaborate a little?

Thomas Frey
User offline. Last seen 5 years 43 weeks ago. Offline
Joined: 15 Sep 2011
Posts: 23
Groups: None

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.
 

wjm014
User offline. Last seen 4 years 3 weeks ago. Offline
Joined: 15 Sep 2010
Posts: 15
Groups: None

These two options were available in earlier mainframe software packages such as Premis and P2 in the 1980s and are not Primavera concepts. I agree with those who recommend doing their homework and using either option for optimal results. I often use retained logic when I need to reduce detail and am unable to foresee accurate logic corrections. For example, in simple sequences such as install hangers - conduit - pull wire - install fixtures - terminate, for very large buildings such as airport terminals it is impractical to establish detailed logic for every ft/m of cable installed. Electrical crews often driven all over the building on a daily basis by uncertainty in other trades. Consequently, you end up installing the work in a piecemeal fashion and retained logic is ideal for scheduling in these situations. One downside of course is that you get a long list of out of sequence errors on the debug report. It would be nice to have a feature that identifies OOS status that can be explained. Progress Overide has functionality in some circumstances also.

Daniel Limson
User offline. Last seen 33 weeks 6 days ago. Offline
Joined: 13 Oct 2001
Posts: 318
Groups: None

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
Stephen Devaux
User offline. Last seen 1 year 31 weeks ago. Offline
Joined: 23 Mar 2005
Posts: 603
I can’t express it any more articulately than Rafael did.

Yes, I have had "sponsors" who have been reasonable on DoD programs -- not always, but occasionally. It’s more frequent with a subcontractor working for a prime -- I guess perhaps they understand the situation a bit better, knowing what they often face.

If someone rejects the idea of a baseline and a working schedule, with reserve, they’re just asking for a padded schedule, with "reserve" built in everywhere. And per Parkinson’s Law, it’ll get used. Much better to have the difference between the two schedules displayed as a separate line item called schedule reserve or, in Goldratt parlance, "buffer".

Fraternally in project management,

Steve the Bajan
Rafael Davila
User offline. Last seen 2 hours 49 min ago. Offline
Joined: 1 Mar 2004
Posts: 4620
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 Sutton
User offline. Last seen 3 years 5 weeks ago. Offline
Joined: 8 Feb 2001
Posts: 28
Groups: None
Keeping 2 schedules is not the entire issue. I’ve been in the business long enough to know how to maintain 2 schedules with minimal effort. Work sequence is adjusted to remediate delays or meet changing conditions, not to game the system.

Having 2 schedules does not keep the Owner from writing poor evaluations, or making/delaying decisions based on uncorrected retained logic.

Or, are you perhaps suggesting that it would be wise to submit 2 schedules, one as mandated by the Owner and identified as a cost tracking tool only, and one reflecting ’reality’? I’d be very interested to hear if that has been a successful strategy.
Stephen Devaux
User offline. Last seen 1 year 31 weeks ago. Offline
Joined: 23 Mar 2005
Posts: 603
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
Rafael Davila
User offline. Last seen 2 hours 49 min ago. Offline
Joined: 1 Mar 2004
Posts: 4620
Tamara,

Perhaps you should consider keeping two versions, one for Contract Management and another for Job Management. The problem is when the owner requires you to use their software of choice and your company uses other software, then it becomes a real burden.

Some owner reps do not understand the difference between a Contractual Baseline and a schedule update. Even when there are no changes in work or schedule sequence the contract management schedule as required by government agencies do not allow us to target for early completion in the hope we finish on time, they are reluctant to accept the use of buffers. In addition, the use of calendar days to model rain shall not be used for short term planning because if it does not rain then early start of some activities might be artificially delayed. Add to this the use of contractual constraints that fool traditional CPM/PDM computations and you got a useless tool to manage your job, this without even considering the changes in logic you just mentioned.

At a time I was uncomfortable with the concept of keeping two versions. Spider Project provides for synchronization of 3 versions and updating in either version automatically updates the other two, even create the new file version id for free.

Here at PP there are people versed with procedure to transfer updating data that can help you with your particular software, instead of a single click of the mouse maybe two clicks will do it. You need a way to transfer updating data only as logic might differ and a few activities might not exist in the other version, these few, if any, you will have to flag to update on their own version when need be.

I believe you have no other option if you want to have an unobstructed view of your Job Management schedule.

Best Regards,
Rafael
Tamara Sutton
User offline. Last seen 3 years 5 weeks ago. Offline
Joined: 8 Feb 2001
Posts: 28
Groups: None
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.
Rafael Davila
User offline. Last seen 2 hours 49 min ago. Offline
Joined: 1 Mar 2004
Posts: 4620
http://www.pmicos.org/topics/aug2003.asp

Beware that retained logic can be handled in different ways by different software, in any case none is a sure solution, you must do your homework.

Because both are temporary calculations until you do your homework I favor none over the other, is very simple; "Both Retained Logic and Progress Override can be equally wrong...", do your homework until all O.O.S. flags are cleared, even if this represent no change in projected schedule dates it does not means it will always be the case.
Gary Whitehead
User offline. Last seen 27 weeks 4 days ago. Offline
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.
Wilfredo Barbacena
User offline. Last seen 2 years 45 weeks ago. Offline
Joined: 13 May 2009
Posts: 30
Thanks for the feedback guys,

The thing is that when you started scheduling in retained or progress override the bar chart are totally different. In both cases the logic should be modified to reflect the near scenario of the project, need to check the contract condition if its permissible. What really makes me nuts is when some PM doesn’t really bother read the schedule or doesn’t really understand the schedule or not at all.
And most of all, you’re correct, it’s all about commercial issues.

In that case it’s my discretion to use when, what, and how.

Many thanks...that’s life and enjoy it
Scarllet Pimpernel
User offline. Last seen 7 years 24 weeks ago. Offline
Joined: 19 Jul 2009
Posts: 152
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
Joel Gilbert
User offline. Last seen 46 weeks 6 days ago. Offline
Joined: 5 May 2003
Posts: 166
To try and answer your question and keeping it short and simple.

You create a schedule with the aid of your team, baseline it then track it.
Along the way activities start before or after the baseline. That is normal and it is up to the Planner to update re-schedule and check the knock on effect and resolve it.

Sometimes it may even mean changing logic, because in the mitigation meeting of slipping activities someone has had a better idea to resolve the problem and bring back the activities and therefore the schedule back on track.

The schedule is a living document and you as Planner must update it and track it as best as you can and if activities slip then it must be so and the end date will slip and management must make decisions to make it happen.

It is impossible for a schedule to be 100% correct and changes will have to be made along the way.

Obviously this depends largely on the type of project and number of activities in a project. i.e it is highly unlikely a project of 20 activities can slip, but try that on a Petrochem or mining project of +2500 activities.

Hoping this helped.
Andrew Dick
User offline. Last seen 2 years 48 weeks ago. Offline
Joined: 14 Feb 2007
Posts: 295
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
Rafael Davila
User offline. Last seen 2 hours 49 min ago. Offline
Joined: 1 Mar 2004
Posts: 4620
Neither retained logic nor project override is a solution, both still leave the issue unresolved and CPM logic shall be adjusted to represent changed course. The software must assume either as to continue ists computations and tell you about the out-of-sequence occurrence. Most of the time our out-of-sequence occurence is solved with a mere reduction in lag, we understand it is not always the case. I consider the practice to require schedulers to resolve out-of-sequence issues as soon as they happen the correct approach even if started and finished within a single updating period, don’t be lazy show adjusted logic even if is just a reduction in lag duration.

The few "all perfect" members of our community cannot accept planning logic is not always the hard logic as they pretend it to be, particularly the forensic analyst who is always right while the other side forensic analyst is always wrong. Planning in real life is very frequently based on subjective rules that you might change as need be, sorry prima-donnas

Perhaps you should look at the most typical relationship culprit of the out-of-sequence event the SS relationship with lag. It is common for managers to overlap activities by means of such dependencies and a lag value. This lag value is kind of subjective or an approximation of a reasonably good value.

It might be, you plan to keep the start of the activities a week difference as to keep the distance between the crews. Say in multistory buildings you keep masonry one floor ahead of cement plaster as to keep crews separate even if every activity takes one week, the modeling of this using SS relationship with lag instead of using a FS relationship is a better model representation of true relationships as you can start cement plaster on next floor even without having finishing the installation of all CMU. Archaic proponents for FS only logic cannot understand this and insist out of logic is wrong, well I encourage whenever possible start earlier and create an out-of- sequence event if this makes sense as the job moves. Note that under either SS and lag or FS no lag relationship the occurrence of an out-of-sequence event will happen if the second activity is started ahead of planned logic. It was just thet the estimated lag is a dynamic number you shall adjust as the work progress.

OUT-OF SEQUENCE IS GOOD, VERY GOOD; JUST ADJUST CPM LOGIC TO REFLECT TRUE MATHEMATICAL MODELING OF THE CHANGED COURSE.

No software gives you the definitive answer you manually must resolve the issue.

Best Regards,
Rafael
Stephen Devaux
User offline. Last seen 1 year 31 weeks ago. Offline
Joined: 23 Mar 2005
Posts: 603
"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
Gary Whitehead
User offline. Last seen 27 weeks 4 days ago. Offline
My advice is always use retained logic. That said, I don’t always follow my own advice.

Bad things about progress overide:
1) Consider the sequence A to B to C, linked with FS(0)
If B occurs first for some reason, using progress overide will allow C to occur before A. So unless you habitually assign every task upstream of an activity as it’s predecessor (which no-one does), progress overide will often generate the wrong schedule once out of sequence (OOS)working occurs.
2) If OOS working occurs, you need to understand why it occured and what the implications are on the rest of the schedule and the project as a whole. Using progress overide hides OOS working and makes it less likely you will do this. As Andrew says, most times OOS working is not a problem, but sometimes it can be a problem far too big to ignore. If you order a transformer before the client has approved the spec, or start construction before you’ve got planning permission, or soak-test a fuel tank before the fire supression system is commissioned, you really do need to know about it. 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.

Good things about Retained logic:
1)When progressing a schedule, it is a good idea to always err on the side of caution. If OOS working occurs, retained logic essentially assumes the worst. this is for the best.
2) Using retained logic forces you to ensure the logic in your schedule always reflects your best understanding of the work. If OOS work occurs it is either because someone has screwed up on site, or the logic was wrong. Most often it will be the latter. -so instead of telling primavera to ignore the logic, why not just fix the logic?! Following this advice will help ensure at the end of the project you have a proper as built programme, as opposed to the task list you get with progress overide.


As I said before, I don’t always follow this advice. Occaisionally I do use progress overide, but only when I’m being lazy and/or don’t have the time to do things properly. Much like smoking, it’s a bad habit I haven’t gotten around to stopping yet, and certainly not one I would reccomend other people take up.
Andrew Dick
User offline. Last seen 2 years 48 weeks ago. Offline
Joined: 14 Feb 2007
Posts: 295
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
Stephen Devaux
User offline. Last seen 1 year 31 weeks ago. Offline
Joined: 23 Mar 2005
Posts: 603
I am in violent agreement with Andrew. As a PM (or a PM’s mentor), the first thing I would do if someone did work out-of-sequence is to shoot them. Then I would bury them in an unmarked grave. Finally, I would use a "progress override" to go back in time and ask them why the hell they did work out of sequence without first getting the work schedule changed.

I presume the work sequence is set up the way it is for a reason. There is huge risk in someone taking it upon themselves to willynilly change that sequence -- it is very possible that huge risk of rework will thereby be incurred. And once we depart from the planned schedule, all its time-related metrics (duration, float, drag, SPI) become worthless -- you might as well use it to keep the Klingons off Uranus.

I always let my team know that I absolutely encourage them to look for opportunities to to compress the schedule. But when they identify such an opportunity, they should bring it to the PM to:

1. Make sure that there isn’t something they may not know that may mitigate against taking their recommendation;
2. Get the working schedule appropriately changed;
3. Take credit for their enterprising efforts.

Fraternally in project management,

Steve the Bajan
Andrew Dick
User offline. Last seen 2 years 48 weeks ago. Offline
Joined: 14 Feb 2007
Posts: 295
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
Anoon Iimos
User offline. Last seen 3 hours 12 min ago. Offline
Joined: 22 Sep 2006
Posts: 1309
Wilfredo,

Of course it bothers. In reality, your activities usually go out-of-sequence, so you will need the "progress override" option.

cheers