Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

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.

Re-created project updates using Spider Project

12 replies [Last post]
Rafael Davila
User offline. Last seen 1 day 2 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229

I am re-creating project updates using the “Blindsight” Method

In this method, it is assumed that the analyst does not have the update schedule for the succeeding period and has no knowledge of the project conditions later than the update under investigation. Therefore, the analyst must stand in the shoes of the scheduler at the time of the project. Note that the progress curve created by this method assumes a straight line.

i. IF: data date (DD) - actual start of the activity (AS) < original duration (OD), THEN:

Remaining duration (RD) = OD - (DD - AS)

ii. IF: DD - AS > OD, THEN: RD = 1

For this I am using the baseline schedule as submitted with some minor adjustments.

I created user defined fields for Actual Start and Actual Finish. These I use to identify activities to update on regular periods because as always plans do not go as planned. I cannot use projected period as planned dates for my updates but shall use actual data I already have on my user fields.

Then I filter the activities to be updated not by filtering as-planned activities for the period but as-built activities that progressed during the period. For this I adapted a look-ahead filter that will look not at projected start/finish but at actual dates on my user fields.

With a formula I can define update period start date as well as update period finish date.

I am struggling with the Remaining duration formula as the above AACEI suggested formulas work well if using a single calendar based on consecutive calendar days with no calendar exceptions.

I would like to know if there is a way to get the remaining duration using the activity calendar.

RD = OD - (Duration in work days/hours between DD and AS for the activity in question)

On each update rain days will be added as they must be considered as non-work time.

I am looking for a formula such as:

RDWT (remaining activity work days/hours) = Duration in work days/hours between DD and AS for the activity in question, duration that takes into account calendar work/days and excludes non work time such as holidays and rain days.

I created an AsBuilt of project baseline activities only, maybe a project truncation of this schedule from DD to Project end can give me the remaining duration that include all non work days if using the hindsight method, but I am not.

Alternate methods for the purpose are also welcomed.

Best regards,

Rafael

Replies

Rafael Davila
User offline. Last seen 1 day 2 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229

Vladimir,

Agree 100% + 1 unit [not a small but a BIG unit].

LOL

Rafael

Rafael,

if change request was approved then changes shall be implemented in the new baseline.

So we have not one (initial) but a set (history) of baselines valid at different moments.

It is certainly applied to scope changes.

When an activity is in progress then those who do the work may estimate remaining duration with higher accuracy. It does not mean that future activity durations shall be changed. These data (actual plus forecasts for activities in progress are collected at Spider Project Input tables and are used for schedule updates. Revision of future activity durations require approvals, estimates of activities in progress is a responsibility of those who execute them and does not require approvals and acceptance.

Best Regards,

Vladimir

Rafael Davila
User offline. Last seen 1 day 2 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229

Going back to what you said; "I discussed your task with our programmers and we decided that it is not hard to create special function that may restore schedule status at any date or even create project archive with intermediate statuses for the project lifecycle."

As per AACEI 52R-06

Photobucket Photobucket

If the Contractor elects to provide a new schedule status and update with a status date immediately prior to the start of the delay, as long as the last submitted update is not far from TIA DD the functionality can be used. It happens very frequently that a delay start at the middle of the month and TIA is being negotiated after the month ended, by that time we have an updated schedule for the end of the month.

If the functionality is based on the Hindsight Method only, then the contractor can make any [shall be minimal] manual adjustments to RD if he chooses Blindsight Method  to recreate the update.

My choosing for Blinsight Method  is mainly because I am progressing submitted baseline with actual durations up to revision DD, so far so good. But it does not make sense to me to have revised durations on activities in progress as per Hindsight Method  but not on activities not started yet as per Blindsight Method.

Rafael

Rafael Davila
User offline. Last seen 1 day 2 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229

Vladimir,

Submitted Baseline shall be kept frozen, the updates shall be on Project Updates and if required because of contractual reasons or because of Delay Analysis on Revised Baseline(s). We shall keep all.

At the moment I have two; the Initial Baseline as submitted [for the record], and the Revised Initial Baseline [for Delay Analysis] with revised logic as a schedule in error cannot be used to model what really happened, cannot model what was the real critical path.

Regards,

Rafael

Rafael,

adding authorised activity to current plan you shall also add them to the baseline.

So it is necessary to track and restore both schedules.

Best Regards,

Vladimir

Rafael Davila
User offline. Last seen 1 day 2 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229

By the way Spider will make the remaining duration zero but if the volume is positive an activity will not be considered as finished and I don’t see much difference if remaining duration will become one or zero hours and will be shown as an activity of very small or zero duration.

Will consider this in my approach, I agree there is not much difference, say duration 1/1000000000000000 seconds can be the unit.

Still must go with the updating from previous updates as new activities will be added, contractor mentioned about 200 to account for change orders, not to mention changes that caused changed preferential logic.

I discussed your task with our programmers and we decided that it is not hard to create special function that may restore schedule status at any date or even create project archive with intermediate statuses for the project lifecycle.

This can be very convenient for TIA as per AACEI when delay event must be inserted between updates. I am using different methodology but TIA is the most common.

If the functionality is based on the Hindsight Method only, then the contractor can make any [shall be minimal] manual adjustment to RD if he chooses Blindsight Method  to recreate the update.

Regards,

Rafael

Rafael,

Let’s assume that an activity was started and actual information is entered.

It may look like planned work time since activity start or previous update is 40 hours but actual work time was 24 hours, so the remaining work time will be 16 hours longer than planned. If the software will calculate actual work time basing on start and finish dates we will get wrong estimates of resource productivity. If an activity is executed the forecast of its remaining duration is usually made by those who do the job. If we know actual finish why to make rather strange assumption that remaining duration will be 1 hour?. The planned performance at that moment may look like we work for one hour then for no reason will stay for several days and then will start to work again. Why not to use actual finish as expected when the work is in progress? It could mean longer duration or less resource workload (4 days with 50% workload is actually 8 days). For me it looks more practical.

I discussed your task with our programmers and we decided that it is not hard to create special function that may restore schedule status at any date or even create project archive with intermediate statuses for the project lifecycle. But setting remaining durations to one hour looks not logical to me.

Your approach shall work. But don’t forget to make remaining volumes positive too if an activity was not finished. By the way Spider will make the remaining duration zero but if the volume is positive an activity will not be considered as finished and I don’t see much difference if remaining duration will become one or zero hours and will be shown as an activity of very small or zero duration.

Best Regards,

Vladimir

Rafael Davila
User offline. Last seen 1 day 2 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229

Your activities are of Duration type and setting initial Volumes to 100 you will use them as percent complete.

A one time operation that I will execute by displaying the column for volume, set the top cell at 100 and click on fill down.

So after entering dates ignore volumes (but don’t forget to make it zero if an activity was finished) and enter actual hours if an activity was not performed as planned (execution at this period was discontinuous – rains, etc.), remaining duration will be adjusted.

A formula will compare actual activity finish versus DD and will make volume equal to zero if activity finished. Instead of entering actual hours intend to let the software compute period duration using calendars after adding calendar exceptions for the period. I was missing this point about volume, thanks a lot for the warning, shall be on the script, not that I am lazy but can forget, scripts are great.

I still don't understand why RD shall be 1 unit if an activity was not finished at the update time. Spider calculates default RD as Original Duration – Actual Duration (work days/hours). Setting RD=1 hour if an activity is in progress looks not logical at all.

The AACEI procedure calls for RD be 1 day (or perhaps 1 hour/minute/second) if Original Duration – Actual Duration (work days/hours) is negative at the update DD, all original duration was consumed but the activity has not finished. At this point you have to estimate remaining duration and it provides for two methods. I selected the method that will set RD to 1 day (or perhaps 1 hour/minute/second). It is here where I am stuck, at the point before running the update and you must enter RD.

I believe the other option might work against the Contractor as might hide when pacing happened. Because the Contractor as any American Contractor did not kept actual records for activities volume of work I do not have the better model that will compute remaining duration based on remaining volume of work [total minus realized volume of work}. I do not understand how to estimate remaining duration that makes sense without volume of work.

I will think about scripts that may help with this process but do not understand how to set actual performance delays or lower productivity at certain periods and creating and linking new activities that appeared during execution.

I do not pretend the procedure to be 100% automatic, for each update I will transfer period rain days using a reference book, new activities, revised logic and out-of-sequence events will have to be manually solved, those are to be solved by using some judgment that shall not be programmed. Then after the manual data fixes the script will do part of the job.

Will try the following.

Run the preliminary update allowing the software to compute RD.

Use formula/filter to change RD to 1 unit for those activities with RD=0 as per initial update but not finished as per Actual Finish on user defined field.

Execute a schedule run, this will be my update after adding all other changes.

Maybe I can set remaining volume of work to 10% instead of RD=1 for activities that should have finished on the update based on actual duration at update DD but did not.

Will it work, any other idea?

Regards,

Rafael

How does remaining duration is computed by Spider, the software used was SureTrak and it does not provides for volume of work. Therefore there is no data for volume of work performance. Is with remaining duration that I have issues, I want to follow the “Blindsight” Method as described latter, and preferably automate the computations using formulas.

Your activities are of Duration type and setting initial Volumes to 100 you will use them as percent complete. When you enter actual start and finish times Spider will automatically shows expected (planned) percent complete and actual and remaining durations in the Input Actuals table. If Volumes do not matter ignore them and work with durations only but remember that material consumption and fixed costs are calculated basing on actual volumes, cost defined as per hour depends on duration only. If you analyze only schedule performance then volumes may be ignored, if you have costs and materials assigned as fixed amounts to activities then better work with them too.

Don’t forget two rules: if an activity is in progress its volume is positive, if an activity remaining duration is zero (finished), remaining volume shall be zero too.

So after entering dates ignore volumes (but don’t forget to make it zero if an activity was finished) and enter actual hours if an activity was not performed as planned (execution at this period was discontinuous – rains, etc.), remaining duration will be adjusted.

I still don't understand why RD shall be 1 unit if an activity was not finished at the update time. Spider calculates default RD as Original Duration – Actual Duration (work days/hours). Setting RD=1 hour if an activity is in progress looks not logical at all.

If actual data on some activity was entered and its execution had interruptions its progress curve will not be straight line. An example: OR=10, after 10 work days its actual execution time (AD) was only 5 days due to some problems, RD=OR-AD=5 work days.

New activities may be entered in schedule at the versions when they appeared or in the Input table (if they were not planned in the previous update but were performed) but less convenient (you will need to place them at some work packages in existing WBSs and link with other activities).

I will think about scripts that may help with this process but do not understand how to set actual performance delays or lower productivity at certain periods and creating and linking new activities that appeared during execution.

Best Regards,

Vladimir

Rafael Davila
User offline. Last seen 1 day 2 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229

If project schedule was maintained in Spider Project you can open archived version at any moment of past project updates.

Project was never maintained , it is a job with a submitted and approved baseline prepared by another scheduler and never updated. The Owner never required updates and the Contractor never prepared updates. The job got into trouble and now I am in trying to figure out the mess. I am trying to generate the performance archives. On every reconstructed update I must add rain days plus performance of all activities and new activities because of changes in scope not included on the baseline.

If you know what activities were performed at any time and want to restore project history then select these activities [can figure it out using a filter I prepared], press right mouse button on the row number of any of them and select Add to Actual Data Input Table [not an issue with the filter a piece of cake]. In this table you shall enter Actual Start and Finish time (if before DD that shall be entered in the dialog of opening Input table) of activity execution and actual volumes and durations (when not as planned). Remaining volumes and durations, planned finish dates, etc. Spider will calculate automatically. But you can make changes to the estimates of remaining volumes and durations if necessary.

How does remaining duration is computed by Spider, the software used was SureTrak and it does not provides for volume of work. Therefore there is no data for volume of work performance. Is with remaining duration that I have issues, I want to follow the “Blindsight” Method as described latter, and preferably automate the computations using formulas.

After recalculation of the schedule and budget new version may be saved and actuals for the next period entered.

I don't understand why RD shall be 1 unit if an activity was not finished at the update time.

It is one of the options on AACEI Delay Analysis methodology I am choosing [“Blindsight” Method], the other [“Hindsight” Method] is based on the actual duration you know after the facts, this option I do not want to use.

It is as follows:

1. Reconstructed Updates
There are two main schools of thought on recreating a partially statused schedule. The first school of thought, called the hindsight method, states that since the forensic scheduler is performing the analysis after the job has been completed, the analyst should use the actual performance dates and durations to recreate the updates.
The second school of thought, called the blinders or the blindsight method, requires the analyst to pretend that the analyst does not have access to actual performance data and simulate the project scheduler‟s mindset at the time the update was actually being prepared. Therefore, the analyst needs to consider what the scheduler would have assigned as the remaining duration for that schedule activity at that time. If the analyst does not have reliable access to the scheduler‟s contemporaneous bases for assigning remaining durations, the analyst needs to be as objective as possible and follow a remaining duration formula.
Outlined below are the two methods:
a. “Hindsight” Method
In this method, the actual status of the schedule activity in the succeeding schedule update period is used to calculate the remaining duration of the previous schedule update. This is delineated in the formula below:
i. RD = actual duration of succeeding update - (data date - actual start of activity) where the data date is the data date of the existing schedule update that needs to be statused.
b. “Blindsight” Method
In this method, it is assumed that the analyst does not have the update schedule for the succeeding period and has no knowledge of the project conditions later than the update under investigation. Therefore, the analyst must stand in the shoes of the scheduler at the time of the project. Note that the progress curve created by this method assumes a straight line.
i. IF: data date (DD) - actual start of the activity (AS) < original duration (OD), THEN:remaining duration (RD) = OD - (DD - AS)
ii. IF: DD - AS > OD, THEN: RD = 1

RDWT is not calculated by formula but if both AS and DD will be entered in the Actual Data input Table actual hours will be calculated taking into account activity and resource calendars.

Yes this is what I mean, taking into account activity and resource calendars, not only activity.

This is where I am:

Photobucket

I believe the best scientific method to estimate remaining duration is by using remaining volume of work instead of mere guess or tossing a coin, but AACEI have no method to estimate remaining duration in their protocol perhaps because they use software that lacks functionality for tracking volume of work and use the information to estimate remaining duration. But this suggested practice is what I got and must deal with it. Got to lower Spider level to the local CPM culture that do not keep track of volume of work. The contractor might know at the building level about some volume of work but not at the activity level for every concrete work activity, for every masonry and cement plaster activity, for every other activity.

After I finish with my formulas a script will follow so at a single click everything will be done after I enter update DD. I just need 20 reconstructed updates.

Rafael,

I just don't understand why do you need it.

If project schedule was maintained in Spider Project you can open archived version at any moment of past project updates.

If you know what activities were performed at any time and want to restore project history then select these activities, press right mouse button on the row number of any of them and select Add to Actual Data Input Table. In this table you shall enter Actual Start and Finish time (if before DD that shall be entered inthe dialog of opening Input table) of activity execution and actual volumes and durations (when not as planned). Remaining volumes and durations, planned finish dates, etc. Spider will calculate automatically. But you can make changes to the estimates of remaining volumes and durations if necessary.

After recalculation of the schedule and budget new version may be saved and actuals for the next period entered.

I don't understand why RD shall be 1 unit if an activity was not finished at the update time.

RDWT is not calculated by formula but if both AS and DD will be entered in the Actual Data input Table actual hours will be calculated taking into account activity and resource calendars.

Best Regards,

Vladimir

 

Rafael Davila
User offline. Last seen 1 day 2 min ago. Offline
Joined: 1 Mar 2004
Posts: 5229

I created an AsBuilt of project baseline activities only, maybe a project truncation of this schedule from Project Start to update DD can give me the actual duration that include all non work days and from this I can get

i. IF: Actual Duration to update DD < original duration (OD), THEN

RDWT (remaining activity work days/hours)  = OD - Actual Duration at update DD.

Will let you know, but if you know a better way please let me know.