(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.
For a forensic claim I need to summarize and consolidate several activities as allowed in the forensic protocol.
This is a job where there is only a Baseline Schedule submitted and an intermediate update that was never submitted. For this reason I have selected the But-For method or Collapsed As-Built as defined in AACEi 29R-03 2011 under section 3.8. Modeled / Subtractive / Single Simulation (MIP 3.8).
I believe a lot of time and effort can be saved to all parts if the As-Built is based on the original baseline with some activities consolidated into a single activity so that only start and finish of this activity is to be substantiated instead of the dates for each of the activities. Similar to summarization but not exactly as there will be no need to guess and substantiate the details of consolidated activities.
My target is to limit consolidation to activities in a chain with no outside links and perhaps very few exceptions modeling the consolidated links using double dependencies not available in any other software.
To this point seems like nirvana, everything perfect. But making sure there are no outside links is kind of time consuming. I need to be able to select my prospects to consolidate and display only the links of the selected activities intead of the confusing web that is displayed when all links are shown.
Is there a simple way to do this?
Best regards,
Rafael
Printer-friendly version
Send to friend
Hi Rafael
There is no such thing as a 100% foolproof delay analysis - the best you can hope for is to get away with most of it.
The most acceptable approach is the Time Impact Analysis (UK Defined) where you need three elements.
1. A responsive logic linked baseline programme - no constraints - no SS FF links or lead lags or any other abominations.
2. An As Built Programme that underlines the tasks in the baseline programme
3. A Schedule of Events that sets down the date of impact on the affected tasks.
When you have these three elements in place the procedure is as follows.
Impact the delay events into the Baseline Programme in strict chronological order of date of impact.
Note where the result compares with the As Built - there will be three possible results.
1. The impacted baseline does not reach the As Built - in which case some other event delayed the work which would normally be presumed to be contractor default
2. The impacted baseline sits more or less on the As Built - in which case you can assume that cause and effect has been demonstrated.
3. The Impacted baseline overshoots the As Built - in which case the work did not follow the baseline programme so it has to be adjusted so that it falls back to the As Built - if you do not know what the contractor did then you have to make your own adjustments based on your experience as to the most likely changes that a contractor would make.
This procedure has to be done for every delay event in your schedule and later impacts may well affect the result of earlier ones.
You must include contractor culpable events to demonstrate concurrency.
You will find all of this and lots more in the Planning Academy tutorial on Basic Principles of Delay Analysis.
One more thing - don't try to use P3 import the P3 into PowerProject and life will be 10 times simpler.
Best regards
Mike Testro
Mike,
I have a submitted and approved Baseline Schedule with logic so all I need is to eliminate all out of sequence logic or broken links, the remaining logic will be kept and must add new activities due to change orders which shall not be an issue at all. In this way I can develop my Collapsible As-Built. The change in logic is simple a whole building was relocated but the construction sequence did not changed, only a delay on the start of the building of about two years because of permitting related to the environmental issue that triggered the change, the disposal of runoff waters on a river at the property boundary that required a sedimentation basin to be at the original building location, compounded by the fact of unforeseen soil conditions at the new location.
The schedule run using Primavera P3 for the only update disclosed no out-of-sequence as all happened early and Primavera cannot discover out of sequence on inactive links. Fortunately I am using Spider Project and it is all there at the links view, no single click of the mouse needed, no need to perform a schedule run to discover only a few active out of sequence events or as in this case none out of many, mostly due to the disruption on the planned sequence caused by this delay.
I also have an updated schedule that was never submitted as the Owner wisely avoided the submission of schedules and the Contractor fell into the trap. This with the daily log, concrete log and payments applications can substantiate the missing dates.
This is a job I did not estimated nor prepared the CPM, I had no prior involvement on this job in any way, and now comes out the scheduler has a conflict of interest and cannot go against the Owner as he performs work for him also.
Anyway I believe the very first step on any modeled claim is to prepare an As-Built. Open to suggestion as my decision was based on the available data.
Perhaps you can suggest a non-modeled method that can substantiate not merely EOTs as these were granted, not difficult to figure out 2 years a bit over 700 days. We are on the monetary issue, we must prove these delays are compensable.
I count on you, but first I must gather the basic data.
I still hope you will provide me with a procedure that have neven been questioned, that have never lost. A 100% fail safe that will make the case even if you do not have any.
Best regards,
Rafael
Hi Rafael
The whole point about a Collapsed As Built method is that you do not need a detailed logic link baseline programme.
You only need to show the planned start and end dates at the same level as your available as built data.
This is because you are not changing the As Planned but using it as a reference point for the As Built.
In Asta PowerProject this would be done by a series of filters loaded into hammocks.
I avoid using the Colapsed as built method because you need to put a critical path into the As Built programme and your guess where to put the logic will be challenged every time - two recent cases in the UK failed on this particular point.
Best regards
Mike Testro
Hi, Raphael.
Your post gave me a lot to think about (that's a GOOD thing, of course), and I have been thinking about it!
I don't know a whole lot about forensic analysis, but it seems to me that Drag calculation could be an "Occam's razor" that helps simplify the process of determining not WHY the delay occurred, but precisely WHERE.
My approach would be to lay out, in the same file, just the planned CP (perhaps starting with version 1, but if you want version 2, 3, 78, or whichever one you want to compare) and the ABCP. Build in:
Then calculate Drag. It should be very simple to see which "chunks" of the schedule, between the milestones, had how much Drag as compared against the planned CP. Then it sould be relatively simple to assign the extra time to the individual activities that caused it.
In the Excel file below, I listed the two CPs, planned in lower case, ABCP in upper case. They shared the first 5 activities (a-e and A-E), with the ABCP tasks taking a total of 10 days longer. Then they diverged where I put in BM 1 (Burst Milestone 1). The two paths (f - j and O - T) merged back later at Activities k and K, so I put a merge milestone right before k and K. The Drag of the ABCP segment where they had diverged (O - T) was 4 days (again requiring more detailed analysis of which tasks caused how much of that). Then the last part until the Finish Milestone is k, l, m, n on the planned CP and K, L, M, N on the ABCP, with the ABCP segment durations having Drag of 3 days.
Yes, to continue the forensic motif, there is a big difference between finding Dr. Black's body in the library and knowing either that the candlestick caused his death or who was wielding it -- but if, as you wrote,..
"Perhaps timing of delay events by the owner will have different impacts on DRAG and the options available to the contractor.
But how to measure the impact?"
...then I think that measuring the Drag of ABCP segments against the planned CP is a great way to narrow down the list of suspects. (And would give Spider another big functionality advantage over Primavera!)
The list of activities, milestones, predecessors and Drags from my example are below, if you want to duplicate the process.
(Drags computed in MS Project by Sumata.com's Schedule Optimizer add-on.)
| ACTIV | DUR | DRAG | PREDS |
| a | 2 days | ||
| A | 5 days | 5 days(Act) | |
| b | 4 days | a | |
| B | 4 days | 4 days(Act) | A |
| c | 6 days | b | |
| C | 5 days | 5 days(Act) | B |
| d | 8 days | c | |
| D | 11 days | 10 days(Act) | C |
| e | 10 days | d | |
| E | 15 days | 10 days(Act) | D |
| BM 1 | 0 days | e,E | |
| f | 5 days | BM 1 | |
| O | 7 days | 4 days(Act) | BM 1 |
| g | 10 days | f | |
| P | 6 days | 4 days(Act) | O |
| Q | 7 days | 4 days(Act) | P |
| h | 5 days | g | |
| i | 10 days | h | |
| R | 6 days | 4 days(Act) | Q |
| S | 7 days | 4 days(Act) | R |
| j | 5 days | i | |
| T | 6 days | 4 days(Act) | S |
| MM 1 | 0 days | j,T | |
| k | 6 days | MM 1 | |
| K | 6 days | 3 days(Act) | MM 1 |
| l | 8 days | k | |
| L | 9 days | 3 days(Act) | K |
| m | 8 days | l | |
| M | 8 days | 3 days(Act) | L |
| n | 8 days | m | |
| N | 10 days | 3 days(Act) | M |
| Project finish | 0 days | n,N |
Fraternally in project management,
Steve the Bajan
Steve,
DRAG is a metrics that relates to the spinal chord of any schedule, the critical path, if critical path matters I suppose DRAG also matters.
Perhaps timing of delay events by the owner will have different impacts on DRAG and the options available to the contractor.
But how to measure the impact?
Reminds me of the issue on how to measure the cumulative impact of cumulative change orders as proposed by Leonard and Gibbs, formulas that have been used in court successfully. Same as the cumulative impact of change orders this can be very difficult to measure although everyone knows there is such effect.
By the way you got it right about consolidation just that selection is on a diferent WBS and consolidation creates a new file, if you make an error no way the original will be damaged. I am still looking for ways to crash Spider without success, even when transferring database data, ... will never give up.
Best regards,
Rafael
Hi, Rafael.
For purposes of Critical Path Drag calculation, I have always thought that the ability to click/highlight whatever activities one wished and then group them together would be a useful thing -- it sounds from your post as though Spider is working on specifically that. Great!
So now I have another question: in doing the forensic ABCP analysis in Spider, are you using its Drag calculation functionality? Is it very helpful? I have always thought it would be very useful in such an application.
Fraternally in project management,
Steve the Bajan
Vladimir,
This is a process before summarization.
Within an actual WBS I wan to select a few candidates to consolidate, some on the existing WBS will have external links but I want to make sure only first and last activity on a chain within this WBS have external links.
Then after my selection I will create an alternate WBS dictionary for my consolidation. Just learned the WBS for consolidation must be full, cannot be Partial wich is great to control access to users on a multi-user environment, I use it for my reporting. It is a matter of getting used to a Beta functionality that is awesome.
I understand if I select some activities other than first and last on the chain that have external links Spider Double Links will provide a better model that using the simple SS/SF/FS/FF traditional links. I also understand this is not the same as using Hammocks to summarize, the most elemental option but that keeps the intermediate activities I want to eliminate as for avoiding the need to get dates that are not needed for the forensic analysis.
I want to see the links in between and coming in/out of a selection of activities I highlight, need not to be continuous nor under the same WBS I am working, eventually some will become part of another WBS dictionary on different phases.
In the following figure you will see two activities hi-lighted in grey, but all links are displayed, I want to see only the predecessor and successor links of the hi-lighted activities only.
For consolidated activities I would like the software to keep all links by substituting all incoming and outgoing with double links for those going in/out at intermediate points and normal SS/SF/FS/FF those at the end points of the consolidated activity. If the job is progressed these activities will be moved same as others with multiple links. Think of the consolidated bar to act as if individual activity links are strong links so that the consolidated bar will be close equivalent. Depending on how the network progress the driving links can change.
It seems to me like the consolidation functionality in Beta testing is what I am looking for although I understand you are still debugging some items like spreading of resource assigments.
Johannes,
Spider is different but some of your ideas can be used for when summarizing which I will do in addition to consolidation, thank you very much. Keep watching what others are doing, always something is learned.
We have unlimited WBS dictionaries/structures we can create, they need not be a summary of the other but can be completely different dictionaries where activities on different phases/WBS on a dictionary can be grouped under a single phase/WBS on any other dictionary.
The above level 2 WBS 601 was converted into a single activity called phase 601 into level 1, it is not a summary bar what you see in the converted schedule below the original. Now instead of 3 activities on level 1 and another 3 on level 2 was converted to 4 activities on level 1. And this is perfect, still I am looking for an efficient way to exclusively look at selected activities links, perhaps a lower level functionality than the consolidation functionality, a complex functionality Spider Team had in development for some time and it seems like they just got it.
Best regard,
Rafael
Rafael,
did I understand correctly that you want to select activities which links will stay after consolidation?
What is wrong if the software will select driving links?
Best Regards,
Vladimir
Hi Rafael
I am using P6.7
I would proceed as follows;
Trusting this helps
Johannes
Email: PPadmin@planningplanet.com
Replies