(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.
Printer-friendly version
Send to friend
if you use progressover ride in construction it will let somethigh that is a physical hard relationship to finish before it is physically possible such as drywall finishing prior to the stud work see image below
for a construction project never ever ever use progress over ride because if you do it can let a hard logic activity to be comleted before it is physically possible
see below see how the drywall can now FINISH BEFORE the studs which is impossible.
Developing project plans in Primavera P6 involves identifying the sequence or network logic in which your activities should occur. The network logic is strategic in the calculation of a Critical Path Method schedule, which is calculated based upon the activity durations and network logic (predecessor/successor relationships). The schedule’s early dates are calculated during the “forward” pass and the late dates are calculated during the “backward” pass. The “optimized” project plan becomes the basis for the “baseline” or target plan, which is utilized for performance measurement. This blog and Primavera P6 Training tutorial demonstrate the options for calculating the schedule when activities occur “out of sequence” thereby violating the network.
The Primavera P6 Schedule Options dialog box enables users to select between Retained Logic, Progress Override, and Actual Dates to identify how Primavera P6 will schedule progressed activities. The video below demonstrates both Retained Logic and Progress Override options.
When using Retained Logic, the activity that starts out of sequence cannot finish until it’s predecessor has finished. The remaining duration of the out of sequence activity will be scheduled to begin after the predecessor is scheduled to finish. Retained Logic respects the network logic.
When scheduling using Progress Override, Primavera P6 ignores the relationship between the activities and schedules any remaining duration of the “out of sequence” activity from the data date.
Download Free Advanced PDF for retained logic and progress override
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/
For project in progress override mode, it is necessary to revisit the logic as out of sequence working and previous assumed dependencies would greatly influence as to how the activities would behave in the network. Care must be taken and unrealistic results must be examined and corrected as necessary.
This can best be demonstrated in the following example. For demonstration purposes consider activities A, B, and C within a simple network and with the pre-defined dependencies.
Simple network
During the course of implementation activity B started out of sequence while activity A is still in progress.
Network on progress (Retained logic)
Given the same progress data but in different calculation modes, it can be observed that activities behave considerably different within the network. Using retained logic, the intended sequence was maintained. On the other hand by using progress override mode, the sequence is no longer followed suggesting that activity C can now finish earlier than activity A. In this case corrective intervention is required to maintain logic.
Network on progress (Progress override)
Thomas: "the goal of building a schedule and using that tool is not to end in a claim, it is to avoid one."
-True. Very true. Other planners, take note.
Rafael: "Even when dates seems like ok and no logic correction is perceived as necessary, not solving issues with progress override as in the above example can be as bad. ... at times it is not so obvious and here is where real problems might arise."
-Precisely. I'm still not clear Thomas on what your criteria are for those OOS which do not need to be corrected, and how you go about assessing this, and how much time this assesment takes per OOS event vs just correcting it in the first place?
Thomas: "Your continued assumption that all logic is wrong just because it is reported on the out of sequence list is a bad assumption to make."
-Wrong. The logic describes the sequence that MUST happen. If something is on the OOS report, it is becuase the actual progress defies this. So either the logic is wrong, or the actual progress is wrong. The very best you could say is that although the logic is wrong, this has no material impact on the rest of the schedule now, and will not do so in the future. And as I've suggested above, the amouint of analysis I'd need to undertake to satisfy myself that this was true would be a longer task, and more susceptible to error on my part, than just fixing the link. -This is why I'm keen to understand how you kake that assesment as I'm guessing you must have a quicker way of doing it?
Thomas: "A project that size should need no more than 2 or 3 people to keep up to date to serve the projects needs for estimating and forecasting time. When you throw the "All out of sequence must be fixed" stupidness into the mix, it is now a 10 man team just to be key punching monkeys."
-Are you exagerating here, or do you really get so many OOS that fixing them all would triple, quadruple or even quintuple your workload? Out of say a thousand activities progressing in an update period, how many of them would you expect to typically appear on an OOS report for one of your projects? And how many of those OOS events would you typically have to fix in order to have the quality of schedule you are happy with?
Thomas: "Retained logic does not ignore logic, it honors the logic"
-It does neither. Retained logc effectively replaces the logic entered by the user which has now proved to be incorrect with another set of "virtual" logic which is influenced by the original logic, fits with the actual progress to date, and may or may not be a true reflection of the future sequence.
You keep showing the same very simplified example and I never said that none of the out of sequence should be fixed.
I said assuming that all out of sequence is wrong or has to be fixed is wrong and a bad assumption.
AACEI knows more than you or me and I would not argue with them when they have allot more expertise and information and case studies to back up their assertions. Also, I know for a fact that the majority of the persons that wrote the recommended practice documents are claims experts that are well aware of all the games people play with schedules.
When schedules are used for claims it is more common to use a performance baseline or as-built baseline. Actual dates and progress are compared to those baseline types as a basis for evaluating contractor performance.
However, the goal of building a schedule and using that tool is not to end in a claim, it is to avoid one. If there is a claim at the end of a project, then the managers didn't do their job. As I said before, only consultants and lawyers win when their is a claim, especially for large projects.
Even when dates seems like ok and no logic correction is perceived as necessary, not solving issues with progress override as in the above example can be as bad. 135 days of float on Design activity is beyond comprehension, at times it is not so obvious and here is where real problems might arise.
That there is no need to fix all out-of-sequence logic when retained logic [the other option] is used as suggested by the AACEI in their Recommended Practice No. 29R-03, I do not agree. I have serious reserves about their recommendation with regard to possible claims you want to present using a modeled procedure after the facts, following their recommendation might get you into trouble.
Schedules are not used exclusively for managing the job but also as a claim tool.
Honoring logic means that the software is adhering to CPM as specifications require.
Your continued assumption that all logic is wrong just because it is reported on the out of sequence list is a bad assumption to make.
Not sure what my comments have to do with P6's capability with regard to number of activities or ability to handle shifts.
I was commenting on the fact that managing very large projects, that have a stupid spec requiring all out of sequence to be fixed, only turns the schedule into a logistical and administrative nightmare. A project that size should need no more than 2 or 3 people to keep up to date to serve the projects needs for estimating and forecasting time.
When you throw the "All out of sequence must be fixed" stupidness into the mix, it is now a 10 man team just to be key punching monkeys.
Have you ever managed a schedule with thousands or even hundreds of activities active in any given update period?
Abdallah,
If you choose retained logic, progress override or any other option available in a few software any of these can be as goo/bad choice on individual out-of-sequence occurrences.
At times retained logic will delay OOS (out of sequence) activities and all their successors more than necessary. Even if not on the critical path retained logic might have a delaying effect on a non critical path activities and if people at the jobsite do not notice the error will follow the schedule at the cost of wasting valuable float. At times progress override will represent a change in plans and no adjustment in logic might be perceived as not necessary. With the OOS events that start and finish within a single update period also no adjustment in logic might be perceived as not necessary. Some people do not fix these occurrences.
If you are working for under a PM type of contract you have some responsibility to all parties, to the owner as well as to the contractors and subcontractors. The responsibility is there no matter of PM at no risk. Good management of available float is as important of management of the critical path.
If in the future there is a claim then not correcting OOS events and disclosing the revision of logic in due time might invalidate contemporaneous methods.
"The Contemporaneous Method hinges on the principle that in order to determine the impact of delaying events, the status of the project must be established at the time those events occurred. In essence, the schedule needs, first, to be updated at the time of the delay and, second, to be updated to incorporate any planning changes to coincide with the contractor’s plan for pursuing the work. The goal of this method is to develop a freeze-frame picture of the project—identifying the delaying event, the impact of the delay, and the plan to complete the remaining work at the time the delay occurred."
If the contract call to solve delay issues using contemporaneous methods and you do not fix all logic this might hide some or all delay impact. The Owner or any cotractor or subcontractor might place a claim against you for negligence on your responsibility on keeping the schedule valid as an analysis tool.
It does not matter which algorithm you choose, anyway at a click of the mouse you can change it. It also matters that the logic is valid and that the CPM can be used as a claim tool.
Thomas,
Retained logic does not ignore logic, it blindly honors a logic that might no longer be a true representation of the schedule, same as project override it is a computation based on an assumption that is not always true.
20k to 30k activity limits was no issue even for already obsolete software such as P3, for many modern software managing over 100k activity jobs and portfoliso is also not an issue. Here at PP some label P6 as rubbish. It is notorious for not being able to model true shift work, a very common task, it even has some limitation on the number of characters for activity ID which for some create issues when bringing a new job to a portfolio.
As a test on how good/bad it is at modeling shifts you can try the following monstruous one activity job.
Activity 1
500cm rock excavation
Resource 1 production 10cm/hr and works Monday, Tuesday and Wednesday 10hrs/day
Resource 2 production 15cm/hour and works on Wednesday, Thursday and Friday 10 hrs/day
If activity starts on Monday:
Monday =>> Resource 1 will produce 100 cm
Tuesday =>> Resource 1 will produce 100 cm
Wednesday =>> Resource 1 will produce 100 cm
Wednesday =>> Resource 2 will produce 150 cm
Thursday =>> Resource 2 will produce 50 cm in about 3 hours
Activity will take 3 days 3 hours.
If activity starts on Wednesday :
Wednesday =>> Resource 1 will produce 100 cm
Wednesday =>> Resource 2 will produce 150 cm
Thursday =>> Resource 2 will produce 150 cm
Friday =>> Resource 2 will produce 100 cm in about 7 hours
Activity will take 2 days 7 hours.
If your software is not capable of modeling the above, simple shift work on a single activity and you have a need for such models then you are using the wrong tool. Every time the activity is delayed, the distribution of work is shifted, when you have many such activities and work on different hour shifts, different days it can become quite complicated. Distributing work by hand is nuts.
A more interesting shift modeling occurs when your activity crew and their productivity varies with seasons, scheduling for shifts is very common.
When our specs mandate for Primavera products we have issues with modeling of shift work just for a start. At the very beginning it also creates issues with the limitation on a single WBS dictionary while in Spider Project we have unlimited, with Spider Project we can use our own WBS required for our portfolios reports and still accommodate for the Owner requirements, a very democratic approach. We find P6 too little for our modeling needs.
It has been documented by others how poor P6 is at resource leveling. A discussion on this theme alone would take a separate thread. Just look at the Aurora reference.
http://www.stottlerhenke.com/products/aurora/Turnaround/2009-10-01_Aurora_WhitePaper_Turnaround.pdf
Same as Aurora Spider Project have the option for algorithm that look for optimal schedules based on project duration. But optimal schedule is not always the shortest duration schedule, Spider project recognizes this argument and provides for alternate resource leveling algorithms that will not look for the shortest durtaion schedule but for other prioritization options that might adapt to other needs as well. When our projects are in schedule we use the alternate methods that keep some prioritization constant from update to update, we resort to the optimization schedules that override these prioritization when probabilites of project finishing on time are low. I do not know if Aurora provides for other algorithms that do not look for shorted duration schedule but we find the proritization implementation of P6 poor.
The list of advanced functionalities available in other software but not in P6 is very long.
Here some consider Asta PP and Spider Project to be superior to any Primavera products, and yes others live and die for Primavera. MSP is my less favorite but some live and die for it, same as for any other. If you are happy with P6 I have no objection same as if with any other software.
Regards,
Rafael
Your background is impressive and does not change my opinion. Project Management is not a sideline and just because someone has an engineering degree does not by default mean they are expert at PM skills or Project Controls. Project Management is as much a specialty as Electrical Engineering or Civil Engineering. If it wasn't, then you could delegate those responsibilities to your secretary.
You could also try starting an email exchange with Ralph Wagner, who wrote one of the documents you quoted, and get his take on the issue of progress override vs. retained logic.
Based on my exchange with him, managing a project schedule that has 20 to 30k activities with a spec that requires out of sequence correction, has created a management problem with only marginal gains in data quality that are not proportional to the effort required.
Retained logic does not ignore logic, it honors the logic, and that is a fact you need to start recognizing. Just because sometihng is reported as out of sequence does not mean that retained logic is ignoring logic. That is a totally incorrect statement.
Also, the only products that PMs understand from my experience, are MS Project type of tools. Professional tools like Primavera require training and experience to use and manage the database for bigger than small projects.
Thomas,
Of course progress override violates CPM logic, same as retained logic it is a computation based on an assumption that is not always true. Contrary to your practice here the responsibility of the planner is to update schedules as close to reality as can be and not to take shortcuts, because they are on the safe side with regard to projected duration is no excuse to provide poor estimates. Here we take the time to check our updates activity by activity same as we do on our estimates.
We also have a school of technology but it is separate of the Engineering School where I got my BSCE, at MIT where I got my MSCE I don't think they have something equivalent, separate from the Engineering School. I got my degree in 1978 when Project Management as a specialization was on its infancy, now I don't think MIT provides for a PM concentration within the Civil Engineering Department anymore. I got my PE taking the same exam the engineers in many USA states are required, it is graded in the US and only pass or no pass grading is issued, therefore the states cannot adjust their curve and makes it uniform among the states and the territories.
I no longer work as a PM, 30 years was enough, I am doing the easy work; estimates, some scheduling and submittal reviews and even prepare working drawings to assist the field personnel in their interpretation of the drawings. Rarely I use my PE seal, not even to certify inspections as when I was doing inspection work a few years ago the PEs under my supervision were the designated inspectors of record as required by our laws where only certified engineers can certify structural works. I am not a professional scheduler as I do not make a living on it, perhaps an estimator, and I am happy at this time of my career I am doing the easy things, finally. As you can see I already adopted your definition of professional scheduler, one that makes his living on doing it.
At MIT scheduling was considered a tool among many others such as operations research, investment analysis methods, management courses (a few available at the Sloan School of Management), legal courses by practicing engineer-lawyers from Harvard School of Law and a few other options, it was a program that accepted students from all engineering specializations as project management is performed by all disciplines. I applied to Berkley graduate school of engineering and was accepted and picked up MIT as it was closer to home, with an MIT club of Puerto Rico that helped with adapting to a new city.
Here scheduling is done by actual PMs that have no problem understanding whatever software is presented to them, so using the tool is not an issue, what makes the difference are the individuals and their understanding of the process to be modeled. Usually our civil works PMs are required a PE with empahsis on experience, our PMs are required to work on estimates at times of low volume of work, it is considered good for the PM to be in charge to be the estimator and the scheduler of his work, in the few occasions time will allow. Here professional schedulers, those that make a living mostly from scheduling can be counted by a single hand as they are on low demand.
Of course we can agree to disagree, it is obvious we have opposing points of view.
Best regards,
Rafael
Lol, I did not make one derogatory comment and for you to suggest i did is out of place.
Your primary language is also not important to me nor do I consider it relevant to this discussion.
Your suggestion that some one needs a license to be considered a professional is also flat out wrong. I am paid money to estimate and I am paid money to produce schedules, for a living. That makes me a professional and I have done it for 20+ years. Anyone that does scheduling or estimating as a sideline, is not a professional at those skill sets and is just performing a task. Last I checked you don't need a license to be a professional singer, or American Football player, or allot of other positions in life referred to as "professional". If you are paid money to do something and it is part of your core business services, then claiming to be a professional is more than justified, in my opinion and many others.
Professional schedulers for example produce cost and resource loaded schedules that are used for the basis for determining earned progress and payment requests. Or to defend a claim for delay or damages. These are things builders have to do to make money or to recover lost money due to bad circumstances. I have a 4 year Bachelor of Science degree in building technology from Purdue University. Also carry professional certifications from PMI and AACE that prove I have the skills. Besides the fact of actually doing the work and making a living and justifying the value of my work by helping customers mitigate risk and recover money.
Quoting academic theory is nice and all and not always relevant to how the real world works. When my customer's customer holds a pay request up due to an issue, schedule or otherwise, getting paid is pretty dang important. Easy to say it isn't when you're not the one counting on the pay request to pay your people and keep your business going. Again, I never said it was the only thing, I did say it was one of the most important.
As a professional that delivers cost and resource loaded schedules to meet Local, County, State and Federal requirements, and help my customers get paid, I stand by my opinion that progress override violates the CPM calculation by ignoring logic and under estimates delays and float usage.
I do what it takes to satisfy my customer's customer and meet the specified requirements while minimizing the effort so that I do not overbill my customer for the product I produce.
Like I said before, we can agree to disagree.
Gary,
Look at my sample job, I added only one activity to make it more complex. This activity has a SS+60d link to Mobilization Activity, can be anything, an insurance, rental of trailers or whatever.
The first figure displays the updated schedule as of DD at end of September, using retained logic. Because the SS link between the new activity and Mobilization activity is still active the algorithm delayed the start of the new activity to DD+60d even when the new activity started before the DD. Kind of hidden but if your software disclose out-of-sequence at the schedule run it can be identified.
The second figure shows an updated schedule where mobilization was stopped due to late delivery of new office trailers or whatever other reason you can imagine. Still the update works as the previous update, Mobilization activity is still active the algorithm delayed the start of the new activity to DD+60d even when the new activity started before the DD. Still kind of hidden but if your software disclose out-of-sequence at the schedule run only the out of sequence event will not be identified. This is common on obsolete software such as P3 and SureTrak that cannot disclose out-of-sequence events still active from previous updates, not sure about P6. Here you need software capable of filtering out-of-sequence still active that started on a previous update to get a better understanding of what is going on.
The last figure shows the last update using progress override which in this particular scenario is a 100% fit of actual conditions.
If you are using software incapable of filtering disclosing previous updates out-of-sequence then in order to make sure there are no active links to previous out-of-sequence events then you got some problem, how best to detect under this software limitation I do not know. Ron Winter has a software that makes up for the P6 missing table on links, perhaps there he identifies broken links in a similar way Spider Project do. It is not going to be direct solution, will require some transfer of data for every change in your what-if analysis while correcting logic but better something than nothing.
If the out-of-sequence activity starts and finishes within the same updating period it will not delay the projected schedule after the DD. If your average activity duration is two weeks I would guess two in three out-of-sequence occurrences falls within a single update period and one in three in between two or more periods. Still if you do not fix logic if in a future you have a claim you will not be able to use contemporaneous methods as adjusting logic after the facts invalidate these methods. Do not count the other side will not question wrong logic, a check for out-of-sequence logic will be first SOP to discredit your schedule, in good software is at a single click of the mouse.
Mike Testro,
If you are around I would like you to paste the out-of-sequence options available in Asta PP. I believe they added a third option, an hybrid of the classical two. It might be a better approximation than the classical, perhaps it makes it harder to detect the out of sequence if you do not take a look at the functionality that identifies out-of-sequence but maybe it gives you a clue that will hit the bulls eye more often.
For us, because we understand the logic in our jobs it is easier to identify the activity that is creating the out-of-sequence flag and solve the out-of-sequence logic than finding out why hundreds of activities are delayed without making any sense. The people on the site need the correct dates on critical and non-critical activities, they coordinate their work based on these dates.
Abdallah,
This is the nature of the software and the modeling needs, get into the issues, do not avoid them. Murphy is always around and while the behavior of out-of-sequence logic is not always as in my example it might happen at the worst moment.
Solving out-of-sequence logic can save you a lot of headaches, in one of my referenced projects it took us less than 15 minute to correct the logic, it delayed one week the payment application submission because it was agreed to be submitted at the project weekly meeting so all parities after the meting can verify on site and place all the required signatures of approval instead of moving the document from office to office. If we had corrected on time the out-of-sequence logic the application would have been submitted a week before.
Best regards,
Rafael
Thomas,
You are taking it too personal, it is not about me nor about you, it is about doing the right thing and debate using the facts for the best interest of all. This is supposed to be a friendly debate, you got to accept the challenge without going into personal attacks. Anyway I will not fall into the error of returning defamatory statements.
There is no such thing as professional schedulers nor estimators, this is not a profession per-se, scheduling is performed by different professionals as well as many others without a professional license.
Here you do not need a license to practice estimating nor scheduling. Plumbers and electricians are required a formal training on vocational schools and the passing of a test but they are not given status of professional, they are referred as certified electricians. In some trades the professional title does not apply while in others the mere fact of making a living performing the trade can label you as a professional, like a professional baseball player. What are the California requirements to label you as Professional Estimator and Professional Scheduler, similar to that of a baseball player or to a plumber? Which are the formal education pre-requisites, vocational school, a Phd or none?
Fixed price is synonym to lump sum contracts, both terms are well known in the construction business, I work my estimates on a per hour basis on fixed price jobs; take it easy, breath and keep composure, if there was a misunderstanding there is no need to get into the personal. As many in this international forum my first language is other than English, at home English as well as Spanish are officially recognized and you can do business on any of these two, my first language is Spanish.
Getting paid is important but it is not all, even a first year management student knows about Maslow's hierarchy of needs and how the basic needs move up and down in importance. If you are satisfied with your pay then other needs surface, among them self-actualization. If you are at the bottom of the pyramid and you are not paid enough then I can understand in your case it is all about getting paid, but this is not my case.
Always do your best.
Best regards,
Rafael
Sounds to me like you are over billing your customer then. If your doing work on fixed price, then you are wasting un-needed effort on your part.
Attempting to find the "true" schedule, or "true" estimate is an oxymoron. Like I said, estimates are measured by tolerances and variances. That is not to say you don't check your work or do your best to make sure you have not missed anything. It is to say that you have a finite amount of time in which to do the work and deliver.
You cannot possibly be working for a GC if you think it's not about getting paid. That is what it is all about. If you don't get paid, you don't make money. Last I checked, people are in business to make money. That is not to suggest that doing shoddy work takes precedence over making money. It is to suggest that we don't spend more than we have to. Spending costs money and the more money the schedule costs the less money you make.
Never said that fixing out of sequence logic is difficult, only that it is time consuming and I personally don't work for free. My customers always appreciate that I don't spend allot of time and still get the job done and they get paid.
Your suggestion that anyone not doing what you do is failing is not appreciated. Personally I only care about what my customers think since they pay my bills.
So basically what you are saying is that you are not a professional scheduler?
As a professional Estimator and Scheduler, I can tell you that they are not the same, what so ever.
Out of curiosity, do you estimate your jobs the way you would plan them to facilitate cost and resource loading?
The more complicated the sample job is the more difficult it is to see what the out-of-sequence occurrence did to unsuspecting activities down along the out-of-sequence impacted path, can be hundreds of activities. Without the software the field personnel would get lost with the complex relations they cannot see, with the software they will still get lost as most of them do not understand the software.
We will do what is necessary to validate the schedule and get true logic and dates, not distorted "insignificant" dates as they are integral part of the whole, it is not only about getting paid. We never include micro-management activities in our schedules, we do not have issues on managing micro out-of-sequence wrong logic, we manage relevant activities, relevant out-of-sequence logic that must be fixed, in our schedules everything is relevant. We do planning for the short term as well as for the long term, correct dates are relevant along all job duration.
We consider good practice to fix the logic in due time, no matter if required or not by the contract specs, we find it easy to fix out of sequence logic because we understand why logic was broken and how to fix it. We do not use "schedulers by telemetry", even if the planning is done by the PM the scheduler must live the job, is not a foreigner to the site, it is common for our schedules be done by the PM itself or the estimator that worked the estimate.
I only schedule jobs for which I performed the job estimate. I make my living doing estimates and shop drawings review for a few general contractors doing work at risk, scheduling is a sideline I love to do. When my clients call me for a schedule it is for a job I worked the estimate, for work they did the estimate themselves they do the schedule themselves.
Your continued arguing that the schedule has to be micro-managed to be useful is misplaced and is an attitude that does not survive in a for profit organization.
So unless a specification requires all out of sequence to be fixed, it is wrong to suggest that a schedule is wrong when a scheduler only fixes the most important of those sequences. This is especially true when all those issues are mute at the end of the job.
Your example is over simplified and only applicable for a capital program level of planning. I can easily provide an example where progress override fails, as I already have.
More often than not work is performed out of sequence to mitigate delays caused by a stakeholder and as such, most delays forecast as a result of using retained logic are more accurate more often than not.
As I said before, we can agree to disagree and as a person working for a hard bid contractor, I will do only what is absolutely necessary to get acceptance and pay app processed.
Since the contractor owns the schedule via means and methods, it is not wrong to say that only the most important out of sequence needs to be fixed. Just because a GC starts Framing, Rough-Ins, Insulation and Drywall with slight lags, when it was all planned FS, does not mean I have to fix anything. Ultimately the logic is still correct that I have to finish Framing before I can finish Rough-Ins, and finish Rough-Ins before finishing Insulation and I have to finish Insulation to finish Drywall. Using retained logic just provides a more conservative estimate for a finish date, not a wrong one, and does so with out the scheduler needing to spend any time attempting to model actual progress. Using progress override that will ignore that logic and potentially show drywall finishing before framing is not a good idea.
If you work for owners, insisting that all out of sequence has to be fixed is a great way to increase billings. When working for a hard bid contractor, it's a good way to price yourself out of a job.
Not sure what sector you work for, and on every job I have ever been on, the owner causes a delay either by incomplete design, change to design, slow RFI response, slow submittal approval, etc., etc., etc. This is not to suggest that GCs do not cause delay. It is to suggest that owners more often than not are the instigator of delay. Also that GCs will perform work out of planned sequence in an attempt to mitigate delay.
I stand by my opinion that retained logic is by far the better option, and that the assumption that all out of sequence issues need to be fixed is false.
I'm not sure what you are trying to say here.
However, interest rates are so low, that banks are looking for any reason possible to deny loans. Why? Cause 4% or 3.5% is not enough interest for them to be bothered to loan money.
Again, scheduling being a form of estimating means that all parties involved have to be willing to negotiate in good faith and understand that estimates are measured in allowable tolerances and variances. IE, as long as both parities are comfortable with the means and methods being used to generate the estimate of time impact, then parties can settle delays as they go and avoid un-needed confrontation later.
Owners using the schedule as a means of holding up payment is out of line almost all the time. Why? Because as long as the owner agrees with the cost loading, and the percentages earned are agreed, then the pay request should go through because the forecast has little or nothing to do with that pay request amount. Especially when post recovery changes usually increase the amount earned slightly depending on how general condition costs are loaded.
From my experience, owners will do what they think they can get away with and do not consider the law or ethics all the time.
Fixing all wrong logic no matter if wrong by error, by a change in plans or an out of sequence event is relevant if you use your schedule to manage your job. If the CPM schedule is irrelevant to manage your job you got to manually take care of all the details. It is a misconception that only critical activities do matter. It is not true that consumption of float is free and has no impact on your probabilities of success.
Retained logic algorithm does not only delays the out of sequence activity, by virtue of delaying the out-of-sequence activities it delays all its successors down the road. It might distort not only a single activity but a full chain of activities making it impossible to the field personnel to correctly manage their job. If for some schedulers correcting the out of sequence is difficult just imagine how difficult it is going to be for the field personnel to manually correct logic on a complex job.
In my sample job I could fix the out of sequence occurrence by simply adjusting the broken link properties from a FS link to a double link that will schedule the end of mobilization after 25% of design is projected to complete. I do not see any rocket science on this adjustment is very easy. What can be very easy to solve using the software tool can be difficult if not impossible for the field personnel to manually figure out the correct dates for all impacted activities down the road. If working under limited resources the manual correction difficulty will be exponentially increased.
Easy, no broken links anymore.
Best regards,
Rafael
Thomas:
"Specifications do not require out of sequence removal because it is understood that by using retained logic, most of the out of sequence issues are non-issues."
-This must be wrong, surely. You've said yourself in previous posts that you fix the "important" out of seqence issues. But you seem to be saying here that since most are not "important" enough to need fixing, the entire concepet of fixing them at all should not be covered under specification? Why not? Most activities are not delayed by the client, but the spec will still cover such eventualities. mosrt delayed activities won't delay the project, but again the spec covers that situation. Most OOS working will not cause the forecast to bre wrong, but surely the spec should cover what to do when it does?
"Why you and others are so hell bent on making project schedules into full time efforts for the smallest of projects is beyond me."
Correct me if I'm wrong, but your central argument seems to be that planners should use retained logic and correct OOS logic only in the minority of cases where it actually impacts on the forecast. Any less gives a poor schedule, and any more is a waste of time & money?
Perhaps it's down to the methodology I use, but to my mind the vasty majority of the time spent in correcting an OOS logic is used to identify and then understand them. Actually ammending the logic is pretty trivial in comparison. So by the time you have spent enough effort to get enough information to be able to decide if an OOS is "important" enough to bother correcting, the amount of effort you'll save in not bothering is fairly trivial. Still a saving, but not a big one IMO. And certainly not enough of a difference that not following your advice would make "project schedules into full time efforts for the smallest of projects"
And of course the other issue is how do you define an "important" OOS? Particularly if specs are silent on the issue? Is it just any OOS that causes an incorrect early date vs the current schedule? how about float calcualtion? free and/or total? How about in progress OOS's that look "fine" now but have the potential to screw the forecast at the next update if not corrected?
Again maybe it's just the way I do things, but it would seem to me that in the time you would spend considering all of the above for each OOS, you could have just as easily fixed the OOS regardless. It's cleaner and less risky and just makes for a higher quality schedule.
My first real encounter with the issues that not solving out of sequence events might backfire happened on a job at the worst moment. In this job there was a clause for the reduction and even reimbursement of retainage from 10% to 5% after 50% completion if the job was on track and schedule forecast an on time delivery.
But our General Contractors are no fools, prior to submitting the schedule as part of the billing process, it was delayed a week in order to present a schedule with revised logic that represent the true plans, the true status of the job.
Similar to my prior example in this debate some activities initially were scheduled to happen without any overlap as they were not critical at the moment. As the schedule progressed the out of sequence event made the scheduled activities artificially critical causing the schedule to project a delay when in reality we were ahead of schedule.
It is very difficult, perhaps impossible, when using the traditional TIA that out of sequence will happen but if using monthly updates for a Widows Analysis it might distort the analysis. Still even when you are required to use TIA it solve only issues on EOT, it does not solve issues on concurrent events. If you want to use the Windows Analysis in a clam to solve the issues on concurrent events, using as a reference your monthly updates, it got to be without out of sequence events. Solving out of sequence events latter on and changing logic in your favor latter on is self serving, is a no no in contemporaneous methods.
My call for doing the right thing on time is not a capricious call is based on a real situation we had on a $10M job, at 50% this makes a reduction in retainage from $500,000.00 to $250,000.00 to be reimbursed at that moment and not after finishing the job. This amount of money represents a substantial change in the cash flow of the contractor, a substantial change in their working capital. No matter how good or bad the economy is doing it is not about the interest to be paid on their limited credit line is beyond this. Under this economy the interest rates are so low that even the federal reserve interest is close to 0%, it does not justify delaying for month or years the payment to the General Contractor under the reasoning that the interest is so low it will have no impact on the contractor business.
Here it is a frequent argument that Federal, State and Municipal governments "improve" their cash flow at the expense of the contractors, an unfair practice. Frequently they will look for any excuse to delay payments as if Prompt Payment Act is written in the air. Federal Government is notorious for delaying payments for any missing comma, even if there is controversy they should fix the amount in controversy and make the payment for the uncontested amount, but they do not, even when common law is that they should pay for the uncontested amount on time. I have no doubt some malicious reviewers do not allow the general contractor to make the schedule adjustments for the sole benefit of their clients at the expense of the contractor. Big fish eats small fish. Do not give them any excuse.
For the record, Fantasy Island does not exist, just so you know.
Specifications do not require out of sequence removal because it is understood that by using retained logic, most of the out of sequence issues are non-issues.
Why you and others are so hell bent on making project schedules into full time efforts for the smallest of projects is beyond me. All you are doing is making it harder for owners to get the best pricing possible on their projects because most GCs will refuse to pay for a scheduler and just make their PMs do it and that will only make the situation worse.
Fact is that retained logic has been specified on every project I have been on for the last 20 years, and all of those projects came to a successful completion, despite the schedule being "wrong" as you suggest.
As I said before, scheduling is a form of estimating and by default is always wrong, just like a cost estimate is always wrong. Estimate accuracy is measured by means of variances and allowances. For a one year project, a forecast that is accurate to ~+/- 1 month is more than good enough. That accuracy will improve the closer to the end of the project you get. IE, when you get to 50% complete, ~+/- 2 weeks would be the expectation.
Trying to make the schedule perfect is a pointless exercise. Better, in this case for sure, is the enemy of good enough. Altruisum sounds good and most always fails when someone attempts to implement it. Why? Altruism is a state of perfection and nothing in this world is perfect.
Schedules help guide projects, they do not determine project success. People that manage the project and make decisions determine project success.
Owners come at the schedule from a perspective of attempting to prevent the contractor from justifying delays. Contractors come at the schedule from a perspective of quantifying delay and protecting their margin.
It's all about mitigating risk and exposure.
I totally fail to see how using a method of schedule computation that COMPLETELY IGNORES CPM LOGIC, and hides / under estimates delays, is a good or best choice. Progress Override wiill completely ignore all CPM logic where out of sequence occurs.
Retained logic will honor all CPM logic and it is up to the user to fix the most important out of sequence events.
As long as a specification requires the use of CPM, then technically progress override cannot be used because that method ignores CPM logic.
http://www.pmsite.com/Forum/tabid/159/aft/958/Default.aspx
My recommendation to any hard bid GC that gets a spec requiring the use of progress override is that they explain this is not their preferred means and methods and that the GC is going to provide the schedule using both methods.
Yes, Owners attempting to specify how the schedule is computed is easily an infringement upon means and methods and thus out of line. The owner owns the project and the money that funds the project. With regard to the schedule, float might belong to the project, the GC owns the schedule and has every right to mange said schedule via their established means and methods.
I think you are missing the point here. This is not a long term trend and no one expects this to be a long term trend. It is a short term trend that has come about due to the current status of the economy since 2008. I have worked with the same GC for 10 years and this is the first time we have had an issue on a proejct with a Sub Default.
The same goes for the public sector issue, short term trend that has only come about due to the current circumstances.
With all due respect, you need to stop putting words in peoples mouths, just to try and prove you are right or all knowing.
Where's the plane boss?
Izam,
http://www.warnercon.com/articles/Article%209%20-%20Handling%20Out-of-Sequence%20Progress.pdf
Frequently some specifications prescribe the option to be retained logic but fail to prescribe a removal of the out-of-sequnce logic. This have led the rookie or unwary to believe it is not necessary to verify logic and even that the retained logic is the always correct fix.
You have to select an option otherwise the software cannot finish the schedule run. Yes it can be either, hey you cannot select none. I have no issue with either option but with the non removal of the out of sequence.
I do what the author says if retained logic is mandated by the specs then I temporarily move to progress override as this makes it easier to follow the continuity without the software splitting the activity. Then after removing the out of sequence logic I change the option to retained logic. Comparing split activities versus non split gives you the clue if the software is incapable of identifying the event. I do not agree with the author that removing out of sequence is difficult, that confronting the PM and the reviewer is an excuse to avoid doing the right thing. You got to confront the reviewer if he is wrong, this without personal attacks, go against the issue, there is nothing wrong with it, on the contrary.
I have even been in the situation where the CPM reviewer sequester the CPM and does not allow the Contractor to make any logic adjustments, to make any change in plans. This forces the Contractor to use two schedules, one for his planning and another to avoid confrontation with the reviewer. I have seen so many specifications that are so wrong that it seems like an incapable specifier took a bunch of specifications and made a bomb with it. This is aggravated when the reviewer is even less knowledgeable than the bomb maker. I have seen reviewers that do not understand how out of sequence can fool the logic no matter which algorithm you choose or which is prescribed and to make it worse do not allow the contractor to make changes in the schedule to appropriately correct the situation.
Thomas,
Fantasy Island is in the Carribean not in the Pacific, it is the US territory of Puerto Rico.
Best regards,
Rafael
Thomas,
Still the statistic is quite disproportionate no matter how you distribute the defaults by CG and subcontractors, even if it refers to all defaults by subcontractors and none by general contractors, is like the general contractors procurement for subcontractors in Los Angeles area is bad, very bad.
Would you say that if a subcontractor performs 4 jobs a year on average he would default on one job? Or is it that some subcontractors default on every job? You should consider hiring subcontractors from out of state if locals are so bad.
Mohd,
The answer is simple, either choice can play against any of the parties, the correct way is not to assume you are on the safe side with either option, no matter what you got to make sure the logic remain unchanged. At time remains unchanged if you choose retained logic algorithm and at times it remains unchanged it you choose progress override. Saying that one is a better choice above the other is wrong. Even the gurus complained that the assumption that retained logic is correct is in fact wrong assumption. A sample job with only one out of sequence activity is enough to prove it.
Good scheduling practice calls for the attention to details, any call for sloppiness shall be called to be wrong, you got to do your homework is the correct answer. Out of sequence can fool in unsuspecting ways the computations that no single algorithm is correct, each is only an assumption to let the software identify such occurrence.
Some software are adding a third option to handle out of sequence events, I believe P6 is one of them, the new option is as unpredictable as the traditional two.
Best regards,
Rafael
Abdullah,
I m sure u didn't got your answer....from the above replied post.....
After looking the forum subject... thought i could get something to learn but i m really depressed people here instead of sharing and clearing the doubts....they keep on talking about what i don't know.
they make the answer so complicated that the viewer/member will get confused and would insist on thinking what the question is.
Thomas and rafael you guys are gr8........
Sorry abdullah i couldn't help you ....
How in the world does 1991 compare to 2011? Unemployment at record highs. Home foreclosure at a record high. Federal spending on infrastructure lower than it should be. GCs that normally only bid on 50mil plus jobs bidding on 3.5mil jobs. We have a market flooded by builders trying to survive by low balling public sector projects. Note, I said GCs and Subs and not Just GCs. Obviously the majority of issues are subs defaulting.
I am in the greater Los Angeles area. 1 in 4 projects are suffering from either a GC default or Sub Default. I am currently managing 4 projects for one customer and we had a roofing sub default just two weeks ago. They provided all the documents we requested and they were checked out.
Bonding does not prevent default, they insure when some one defaults and not all bonding companies are equal. They are trying to survive with less staff like everyone else.
I would search the internet and provide relevant links, however this is something happening now that no one wants to talk about.
As far as who is to blame? Let me provide a list
1. The low bid system is a failure and only encourages people that make mistakes getting jobs.
2. Little or no pre qualification required for 9/10 jobs with public entities.
3. Public Entities are opposite of smart enough to think they can actually get jobs delivered for allot less money than they paid 2 or 3 years ago.
4. GCs that are not really qualified to build certain types of buildings, good bonding or not, are bidding on everything.
5. Subs coming from the housing market trying to build stuff they are not qualified to do.
6. Owners in general using the economy as a weapon or excuse for not having to pay for delays or extra work.
7. Public entity personnel purposefully delaying projects in hope of another project coming up or to prevent getting laid off.
8. GCs and Subs using sub par labor to save a buck.
Your sarcasm that scheduling has anything to do with a garbage economy is not appreciated.
So what district do you work in? Fantasy Island?
Btw, can I barrow your time machine? I would like to go back to 1991 knowing what I know now.
Thomas,
The market is flooded with incompetent contractors atm low balling every job possible in the public sector to the point that about 25% or more of the public sector projects are facing GC or Subcontractor default.
Wow, your statement about contract defauls is atonishing. In what jurisdiction do you work? Shall we blame your scheduling practice, the Contractors or the Owners who know little about good procurement practices? Who is to blame for such bad performance in your jurisdiction?
Here even municipalities require Payment and Performance Bonds, this is our basic inmmuniztion vaccine against default. Even if our municipalities have 10X of what the Federal Government has on their jobs it would amount to about a 1%; 25% would be 225 defaults for every 900, it is 225X our Federal Government experience. And I call them the bad guys.
Best regards,
Rafael
I provided a solid example of how out of sequence can occur and where retained logic is more than adequate for providing a proper forecast without needing to fix it. Fixing out of sequence is very time consuming and on large projects simply a burden that results in over priced services. If a person is on salary it is a good way to justify allot of extra time for a single project.
When we manage a CPM network, we make the changes that make sense and that are needed to provide a reasonably accurte estimate of performance and float consumption. I peronsally have serviced the same hard bid contractor for over 10 years and 30+ projects using this approach and not once has my customer been assessed LDs. More over they have recovered enough money via delay negotiations to justify my continued participation for those 10 years. We have always used retained logic and we always provide a performance baseline to prove we have a viable plan vs. performance.
Competent contractors with good schedulers cannot deny when a delay occurs and input of performance / actual progress will show just that in an adequate schedule.
I can only formulate an opinion based on what has worked for my customers in the real world and kept me in business.
The market is flooded with incompetent contractors atm low balling every job possible in the public sector to the point that about 25% or more of the public sector projects are facing GC or Subcontractor default.
Again, scheduling is never going to be perfectly correct, anymore than an estimate is the right number. Scheduling is a method for estimating time and estimates by their very nature are wrong and based on assumptions at some level. This will be true regardless of when the estimating is performed.
I think we can agree to disagree, for the most part.
I DID SAY THAT NOT ALL HAS TO BE FIXED FOR THE SCHEDULE TO BE AS ACCURATE AS POSSIBLE.
Yes this is true when the assumption by the selected algorithm matches reality, the issue on requiring to eliminate all out-of-sequence flag is that it makes sure all are fixed. Fixing out-of-sequence flag is easy it is good practice to fix them all.
The real problem comes when an incompetent CPM reviewer does not allows the contractor to make changes in the CPM unless it is specifically required by them. If the intention of the contract is to make the contractor responsible for the schedule, for the delivery on time, then any clause that prevents him from control the means and methods, to make any changes in the schedule he deems reasonable at any time is in conflict with the general intent of the contract. General intent shall prevail. In most contract where time is of the essence the Contractor is responsible for the schedule, the Owner has a right to be informed of the contractor plans but not to obstruct his control on the means and methods. A change in plan do not relieve the contractor of his responsibility.
Yes no contractor places a delay claim knowing it is his fault, better try to negotiate in a friendly manner, the problem is when the owner creates the delays and want to take advantage of the contract clauses he purposely wrote.
Yes few incompetent contractors exist, they do not last much, gravity takes care of them, but somehow a few manage to survive for some time.
Yes contemporaneous delay claims and resolution performed on time even when based on not perfect assumptions on what will happen in the future is better than a late forensic analysis after the facts, in general after the facts analysis will yield more precise results but rarely a better and more economical solution. Fortunately contemporaneous methods are also 100x easier to apply than the so called forensic methods.
Enforcing wrong logic is better than ignoring logic. Ignoring logic is a complete violation of the CPM calculation.
Again NEVER SAID THAT OUT OF SEQUENCE SHOULD NOT BE FIXED. I DID SAY THAT NOT ALL HAS TO BE FIXED FOR THE SCHEDULE TO BE AS ACCURATE AS POSSIBLE.
Your assumption that all reported out of sequence items on a schedule report have to be fixed in order for the schedule to be compliant is wrong and misleading.
It is always better to settle delays as you go and waiting to till the end increases the risk of litigation. The only people that win when claims go to litigation are the lawyers.
I have worked for both contractors and owners. I can say with out a doubt that owners are the problem more often than not and cause more delays than a competent contractor ever could, even if trying.
I DID SAY THAT RETAINED LOGIC IS MORE CORRECT BECAUSE IT ADHERES TO THE RULES OF CPM BY NOT IGNORING LOGIC. - But it can enforce wrong logic that was made wrong by the out-of-sequence events, your statement should be RETAINED LOGIC IS LESS INCORRECT, saying is more correct, say 60% correct is misleading. Do your homework and fix the logic even if you work for free, ironically frequently those who overcharge are the most lazy. Here the Gururus are correct.
Whether the claim for delay is made now or at the end of the project, it is still a claim. -The methodologies for claim might vary if made on time contemporaneous methods hold versus if at the end contemporaneous methods might not hold, especially if the logic was wrong as in the case of out-of-sequence and not fixed on time, at the end it is too late to argue 6 month ago my plan was another thing.
The schedule is both a management and claim tool. Whether the claim for delay is made now or at the end of the project, it is still a claim. Schedules are not just for planning what you need to do now, they are also tools for quantifying changes to scope and forecasting that impact. The smartest most professional and proactive owners will negotiate delays as they happen so that any risk of a claim at the end is mitigated. Owners that refuse to entertain claims until the end are the ones that have the most claims that end up in litigation.
Any management team that assumes all their players are intentialy trying to fool them is being dense. As a consultant that has worked with Primavera software since the 80s, I would not bother to waste my time attempting to create schedules just to fool someone. Takes too much time and effort to build a schedule in the first place that I would price myself out of business trying to make schedules just to fool people. Maybe people that collect welfare salary have time for BS like this.
Just because an Agency or any entity has a scheduling spec that requires a specific tool or outlines parameters for building a schedule, is in no way directly proportional to wisdom. 99% of specifications are written by outside consultants and it is up to the entity to enforce them and 99% of the time they lack the skill to even do that mostly correctly.
Your example of how progress override supposedly fixes an issue is over simplified. In a real schedule, progress override will more times than not will create bigger errors by ignoring logic. All to often out of sequence occurs because the contractor is doing everything possible to work around an owner issue. You start framing and cannot finish because you find a location that is not designed correctly. To offset this issue, you start insulation and drywall and then discover that you have areas you cannot dry wall yet because the mechanical / electrical cannot finish due to incomplete design, so then you start painting where you can. Progress override will ignore the valid logic that you have to finish framing and rough-in to finish drywall and finish drywall to finish painting.
Schedules and retained logic do not create problems for projects. People create problems for projects with incomplete designs, poor performance in the field, major change orders, political decision making, inspectors tying to delay projects for fear of being laid off, managers that refuse contractors progress for petty reasons, owner consultants that think the schedule should turn into it's own mini project, refusing to talk about delays, etc, etc etc.
Schedules are nothing more than a model for estimating the status of a project. Estimates by their very nature are always wrong. Just like cost estimates.
Retained logic doesn't favor either party and is just more correct at reflecting delays. Progress Override, because it ignores logic will be more optimistic and hide delays more often.
NEVER said that either one of the methods is a panacea. I DID SAY THAT RETAINED LOGIC IS MORE CORRECT BECAUSE IT ADHERES TO THE RULES OF CPM BY NOT IGNORING LOGIC.
Good luck using progress override. - Read the comments, same as Retained Logic it is no sure fix, don’t be lazy correct the logic, this is what the Gurururus are calling for, and is the first time I agree with the Gurururus.
If a schedule is not for quantifying and understanding delays and performance, what is it for then? -It shall be a management tool not a claim tool, the statement implies it is more important what happened than what is going to happen.
Limiting how many activities can be within two weeks of the critical path? And we wonder why our government is so screwed up? – I have no problem with this issue I can create hundreds of irrelevant activities as to fool the statistic. Another of the thousand ways to skin the cat can be inflating some initial activities duration that create float, as soon as performed then the float is reduced on hundreds of activities from 2 week + 1 day to zero. Fortunately the Architect and the Inspection usually are bad at scheduling and they wont notice that even float can be fooled using calendars, especially when the software they specify is bad at disclosing changes in calendar exceptions so even tricks that should be discovered are not.
Government agencies are wising up. – Yes to the point they specify brand name software contrary to good public administration practice, even against the law. The best wising up example in the USA is the GSA or General Services Administration that in a 100% of their jobs they brand specify the selection of the scheduling software the Contractor must use. In some specs they even require for an external scheduler be hired, this is perpetuating bad management culture, management by remote control. But I would not call it to be wising up. A few years ago on a Hangar repair at Roosevelt Roads Naval Base (closed not long ago), the GSA specified SureTrak, our software of choice at the time, to end up losing in federal court, as usual. Seems like now they are moving to more dysfunctional software specification in the hope to make it harder for the Contractor to prove their claims.
Sometimes they look like really wising up when in some jobs require statistical analysis and use of Monte Carlo but the dumbs do not understand that the idea on using these methods is to determine your probabilities of success, that the deterministic schedule probability of success is low and the best way to increase the probability is by using buffers, by targeting for earlier finish date in the hope of finishing on time. The proof they do not get it is in their requirement to use all contract time in your schedule, therefore it is stupid to require an estimate of probabilities for no practical use.
Btw, since when does Richard Faris build schedules for hard bid fixed price contractors? Or O'Brien or that lawyer they mention? – I agree, I believe they represent the prima donna Project Managers that perform work 100% at the risk of the Owner. Neither is my favorite, starting from their argument that float is free for whoever uses it first, the British practice is different and is 50 years ahead. If Owner consumes float of all activities it will put in a very bad position the contactor, it will be almost impossible to finish on time, the British are wise enough to recognize this. Yes you can claim disruption but the message is misleading and makes it harder if not impossible to negotiate the issue, forcing litigation.
Only time it will ever be advantageous to use progress override is when you rep an owner and are trying to deny delays by ignoring logic. - Why do all industry Gururus are so fool that they still provide an algorithm for project override when they should know reatined logic algoritm is 100% correct? Perhaps they realize that very often the correct schedule projection is not the retained logic algorithm projection. It is a misconception by wannabe Gururus that the retained logic algorithm by its name "retained logic" is magically correct with regard to logic. It more often than not artificially delays the job further than correct revised logic, is the call of unscrupulous owners who want to corner the Contractor by any means as to take whatever advantage they can.
Just look at the following design-build schedule where mobilization is out of sequence, mobilization was originally scheduled to happen after 100% design but the Contractor was asked to mobilize without 100% design. A premium was paid by the Owner but even when he mobilized over ten weeks ahead of schedule the updated schedule shows a week saving instead of a saving of about ten weeks. The schedule was updated at the end of September using retained logic.
The following update was performed using progress override, in Spider set by selecting "Ignore preceding activity links if activity is in progress". In this particular case progress override yields a better representation of true logic that was changed by the out-of-sequence event. Construction could start after 4 weeks, at about 25% design , meanwhile as initial construction pregressed design was finished to 100% at about 25% construction.
Still the correct procedure is to correct logic as to erase the OOS or Broken Link Flag, in this way your assumption about which is the correct answer is validated or proved wrong, frequently the correct answer will be none of the above but other. You shall do your homework and erase all flags for all updates. If your software only gives you the flag on the current schedule report then you must figure out all pervious occurrences.
And the list is endless, I am anti-PMI.
Abdallah,
Although usually retained logic results in a delay in favor of the Owner in the above case because the Owner asked for early mobilization and the retained logic algorithm projects a longer job duration then would you say it is an Owner caused inefficiency, an interruption of work, when in reality the effect is the contrary? True effect is a substantial saving on project duration. Out-of-sequence events algorithms do not solve the issue, the algorithm selected is an assumption for the schedule run be completed and the out-of-sequence events be identified, then a correction of the logic must follow. The Owner was wise enough to figure it out the out-of-sequence was very good strategy and that retained logic algorithm prediction on the first schedule update was wrong. He did not panicked, he simply fired the dummy who was requiring blind application of the retained logic algorithm.
Unfortunately this hypothetical case do not represent reality, frequently the dummy prevails, creating a lot of trouble to all parties.
Here are two totally absurd statements from that article:
From: http://enr.construction.com/features/bizlabor/archives/030526.asp
"
Another phenomena worth noting, says Kent D. Pothast, scheduling manager for Portland, Ore.-based Hoffman Construction Co., is that schedules often are anticipated as tools in claims and lawsuits. As a result, what may have started as a pure construction schedule is written to include owner decisions, architect's timely submittal of drawings, approval processes for changes and other data. The common result, whether float is being added or eliminated, is "you are trying to keep somebody off you or put pressure on somebody else," says Pothast.
Some contractors set up schedules in which anyone else's delay of any kind allows them to file for more time and money. Government agencies are wising up, however. At least one agency now specifies how many activities can be within two weeks of the critical path to stop contractors from putting in semi-artificial activities to get rid of float, says Pothast.
"
Owner and architect decisions do impact schedules!
If a schedule is not for quantifying and understanding delays and performance, what is it for then?
Limiting how many activities can be within two weeks of the critical path? And we wonder why our government is so screwed up?
If I were you, I would not quote that article anymore.
Btw, since when does Richard Faris build schedules for hard bid fixed price contractors?
Or O'Brien or that lawyer they mention?
LOL
I read your first reply.
Fact is that Progress Override ignores logic ties that completely blows the CPM calc out of the water.
Never said that Retained Logic meant the user did not have to fix out of sequence issues. Only that not all are required to be fixed and that if a specification does not require it to be fixed it is done at the contractor's discretion. Means and Methods.
Your post gives me the impression that you think everything is black and white, right or wrong.
Fact is that smaller projects do not need to be consulted into a blow out price for the schedule and if not fixing every out of sequence issue is adequate, then good enough is the way to go.
Only time it will ever be advantageous to use progress override is when you rep an owner and are trying to deny delays by ignoring logic.
Richard Faris is marketing, period. Allot of other people mentioned have their heads in books and clouds and not the field.
Anything in a software tool for the well trained can be used to fool the ignorant. Just because tasks have different calendars does not by default mean the user is abusing the software. We use a different calendar for outside work / work that can be impacted by rain all the time. Great method for quantifiying the impact of rain days and has past muster many times.
How about we put JD Powers and AutoCADD and PrecisionEstimator and all the other commercial software out there in the hands of the secretaries. Who needs educated engineers and managers anymore.
I stand by my opinion that in my experience of representing profit motivated hard bid fixed price contractors that retained logic is the only option for obtaining a realistic schedule that effectively quantifies delays and impacts caused by any stakeholder.
Good luck using progress override.
From: http://www.htcprojectcontrols.com/SB002.pdf
Can be further summarized from a reference I no longer have the link:
"Both Retained Logic and Progress Override can be equally wrong if the scheduler merely accepts what the program spits out."
Not doing your homework is the lazy scheduler approach or even worst, the irrelevant scheduler that spits out whatever the computer says without realizing either option is not a sure bet, irrelevant scheduler because even the PM does not realize the error but does the correct thing on the jobsite, he no longer trust the scheduler nor waste time explaining the scheduler who insists the computer is correct and forgets about GIGO.
As stated on the first reference a good scheduler can figure out how to fix the out-of-sequence occurrence without need to ask the Contractor. Only in a few occasions he shall be in need to consult or verify the assumption.
For the fist time I agree with the self proclaimed Gurus, you got to revise logic.
From: http://enr.construction.com/features/bizlabor/archives/030526.asp
In my opinion, the use of Progress Override or Retained Logic without doing your homework, without revising logic as to erase the out-of-sequence flag is a lazy attitude by organizations that lack the skill to manage projects without being part of the problem. Erase the out-of-sequence flag, 22 years of doing the wrong thing is no excuse.
In my opinion, and from 21 years of experience, retained logic is the way to go for any planning in Primavera Software.
From my experience this method will provide a more realistic and achieveable forecast and provide more accurate information in regards to delay.
See this document and in my opinion this document provides enough information for you to make your own choice:
Neither Progress Override nor Retained Logic solve the issue on the out-of-sequence occurrence, you still must solve it by performing appropriate schedule adjustments. Our experience is that most of our schedule out-of-sequence events can be solved by merely reducing some planned lag, a reasonable plan that latter was revised by actual performance and the missing element was just to adjust the planned lag values.
To solve the issue just filter for out-of-sequence broken links and work on the required adjustment, updating a schedule is not merely plugging actuals but also about reflecting change in plans.
Even if the adjustment has no impact on the schedule it should be performed and justified as to document why it happened and to show adjusted and valid logic. As you continue with the corrections your final filter for broken links shall be empty. In our specifications we are required to fix and justify all such occurrences although in practice it is not always done.
Pretending either Progress Override or Retained Logic is a good fix, is wrong, both are intended to set a temporary rule to allow the software to finish its schedule run, to allow the software to identify the occurrence for you to fix it as there is no way the software can magically predict the true correction to be applied.
"Both Retained Logic and Progress Override can be equally wrong if the scheduler merely accepts what the program spits out."
Email: PPadmin@planningplanet.com
Replies