Resource Overloads Bar and Resource Dependencies

The following scenario will showcase the difference between the diagams and the pre-defined overloads report.

The above diagram does not provide enough detail about the overload duration.

The above diagram is better but error prone and time consuming.

The above report give us the details up to the minutes, this is best report.  There were two overload events, first lasted 1 hour and second 8 hours.

This report I want to be available for materials and financial resources.

BTW I am looking for the formula to calculate resource overload duration using resource calendar.

The following short videos showcase why I say Resource Overloads Bar can be misleading.

The ability to find out overloads using the overloads bar is sensitive to the time scale.

Even if the timescale is widened it still can be misleading as when multiple resources, each with their own overload events, each event with their own time span it is difficult if not impossible to figure it out where to click on the bar to hit each and every overload event.

Rafael,

did you press Resource Peak Workload button?

Resource overload bar shows resource overloads after resource peak workloads are calculated.

You can set automatic calculation of peak resource workloads together with project scheduling in the scheduling/leveling options

did you press Resource Peak Workload button?

• After selecting automatic calculation of peak resource workloads the bar works as expected, not sure about the Resource Peak Workload button.
• Anyway it is still tricky; perhaps automatic calculation of peak resource workloads should be the default option or maybe could be toggled on for simple scheduling and off for resource leveling scheduling. 
• Also if when resource leveling there is a warning about not enough resources to level the schedule changing the bar display can be a fixed visual warning this happened.

I might change my opinion about the bar as it will be a visual indicator of any overload, no matter what resource.

Thank you for the warning.

Best Regards,

Rafael

Resource overload bar is the indicator of any resource overload.

Pressing right mouse button on the red area you will get the report on what resources were overloaded at that moment.

Resource peak workload calculation takes time and it is up to the user if to do it together with scheduling.

The warning of unsufficient resource quantity is shown when some activity requires more resource units that are available.

Resource peak workload shows the maximal number of resource required at any time, not only resource overloads.

I never trusted how resource dependencies are shown, perhaps enough for the software to level the schedule but not enough to show all dependencies. 

Before leveling there are some overloads.

After leveling the so called Resource Dependencies can be shown.

The Resource Dependencies shown can be misleading. Activities 3 and 4 are delayed not only because of resources on Activity 1 but also because of resources on Activity 2.

• Resource dependencies are internal calculations that might be better if not shown. 

The overloads report list all activities causing the overloads, this report is never misleading.  

For the Resource Overloads Report to include materials/consumable resources as well as financial resources overloads is of much value, for me a big deal. 

Rafael,

you remember that in Spider Project Resources are only rebewable resources.

Cost flow can be shown in the separate report where all cost "overloads" are shown like in this example

We do not special bar for materials "overloads" though material flow may be shown for any specific materials.

Resource dependencies are the result of resource constrained schedule analysis done after leveling. Resource dependency shows why an activity is delayed more than logical dependencies require. Besides they may be useful when Spider Project schedule is exported to another tool. One of the export options is exporting all dependencies including resource dependencies. In this case the schedule calcuated by external tool will be the same as the leveled schedule in Spider Project. We think that resource dependencies are useful for these two purposes: schedule analysis and schedule export. And once again by resources we always mean renewable resources.

You are right that it could be useful to show resource dependencies for portions of splitted activity.

Material dependencies are more complex. Next activity may start not only when another activity that consumed the same resource was finished but if its consumption rate became lower for some reason. In any case it is another task.

But what about materials/consumable and financial resource overloads?  

As most construction schedules have materials/consumable and financial resource constraints I consider it a joke the claim these other software are good enough to efficiently handle resources. 

The bar is against Spider itself. 

In a prior post I said that the Resource Dependencies can be misleading and these are internal calculations that might be better if not shown.  A 180 deg. turn from my request to display even more.  Maybe the resource leveling algorithm does not make use of temporal links but temporal dates as I believe MSP does.  If this is so why show something that is incomplete or not real? 

But why not transfer delays caused by leveling of consumable as well as financial leveling? 

I know most external software will not even recognize the existence of consumable and financial constraints but they are still relevant.  

It is important for consistency and transparency that those receiving the Spider Project Schedule transfer get the delays caused by leveling of consumable as well as financial resources leveling.  Maybe visibility will be available if consumable and financial resources are transferred as non-leveling regular resources along with their corresponding dependencies.

They might not be able to dream leveling consumable or financial resources but will be able to see what they are missing. 

Rafael,

they do not model financing and supplies and delays are usually caused by delays of funding and supply.

And links may be complex because Spider Project schedule activities so that materials appear exactly at the moment when they were totally consumed. The link may lead to the middle of succeding activity.I am not sure that negative costs and materials can be exported to other tools.

Maybe there is still a way to show these multiple interruptions.  Maybe an unorthodox idea such as creating temporary calendars and exceptions to represent the resource dependency can do the trick if there is a way to transfer such exceptions.  Just a crazy idea in the hope something could come out of it. Never give up.

I have no problem whatsoever with how Spider works resource leveling. But when transferring resource leveled schedules to other software I have problems, I am looking for some workaround with the understanding these resource leveled schedules are a snapshot. 

I believe Spider might have the required functionality to calculate the splits as calendar exceptions down to the seconds.

More challenging might be to transfer interruptions among different shifts on same activity.

For years I have been frustrated by how little functionality is on P6 that makes it impossible to mimic snapshots of more functional software such as Spider Project.

Even if some resource dependencies cannot be transferred to less functional software having access to them within Spider Project will be useful. 

Rafael,

I have to agree with Vladimir, in the sense that drawing links between financiar and material constraints could be difficult to realize and somewhat abigous to read; however if I may suggest, as it is now, Spider draws resource links between activities, maybe it could be made in such a way as to draw resource dependencies between resource assignments or maybe an option to have both: in the Gantt settings there is an option called Resource dependencies, perhaps a sub-option called Draw resource dependencies at assignment level would prove more reliable when showing them; even perhaps draw them in the Resource Gantt diagram.

The functionality will imply only drawing the resource links at the assignement level, while maintaining them between activities in the links table, this way the export resource dependencies as links will not be affected.

Best regards,
Bogdan

It is not possible to export assignment dependencies because they do not exist in other packages.

So the users have a choice if to export all dependencies including resource dependencies, or logical dependencies only.

In the first case their package will keep Spider schedule, in the second case it could not be guaranteed.

It seems I haven't made myself clear.
From what Rafael wrote I derived the ideea to keep resource dependencies as links between activities in the links table but to have on option to display (draw) these resource dependencies on the Graphic part of the Activity Gantt from resource asignment to resource assigments, Spider identifies these "links" (delays) in a tabular form in the column "Reason for delay".

For me, the resource dependencies between activities and the column Reason of delay is enough to drill down the schedule; what I would like in the Schedule report, if it is possible, to mention the amount of delay and the other activities that use the resource, for example:

Activity "Activity 3" (Code: 3) is delayed due to the lack of Resource "Resource A" (Code: A) from Activity "Activity 2" (Code: 2), for 24 hours, 3 days using calendar 8hd5wd.

Activity "Activity 3" (Code: 3) is delayed due to the lack of Resource "Resource A" (Code: A) from Activity "Activity 1" (Code: 1), for 4 hours, 0.5 days using calendar 8hd5wd.

Where the calendar 8hd5wd is the calendar is the calendar of the activity which is delayed.

I think this information would be very useful.

Best regards,
Bogdan

Anoon,

Resource overloads may happen in any schedule including those with only FS0 dependencies.

Activities have logical dependencies but may be delayed when required resource is busy on another activity.

Analyzing resource constrained schedules we show why an activity is delayed if it is delayed more than logical links require. So we create and show resource dependencies that show what activities used the required resource and caused activity delay.

Activity sequencing is determining activity logical dependencies that must be followed. Resource leveling considers both these dependencies and availability of assigned resources and creates feasible schedule. PM software vendors automate this process and try to create the best possible (shortest) schedule. Manual leveling is possible but is very time consuming and rarely provides good results.

Bogdan,

the problem with multiple resource dependencies: they may create an impression that all preceeding activities shall be finished for the current activity start. But they are of OR type. Resource dependencies are just the indicators that show where to pay attention. They are also useful for exporting leveled schedules to other projects.

Rafael,

dates do not show why an activity is delayed.

Creating multiple resource dependencies creates an impression that all preceeding activities shall be finished for current activity to start. Yes, this is the compromise but useful.

Resource dependencies are always ambiguous.

Before leveling: Please note there are no links among activities.

After leveling:

To created resource dependencies adds ambiguity and can be misleading. It was the use of resource by Activities 1 and 2 that delayed Activities 4 and 4.  

To say the delay reason for Activity 3 and Activity 4 is availability of resource A by sept 9 is not ambiguous. Unfortunately some are missing, activity 4 was delayed and no delay reason is shown.

I understand the main purpose of creating resource dependencies is to be able to create a snapshot of the leveled schedule that does not depends on resource leveling, that uses not all but some of the dependencies as to keep it aligned.  The same can be done in other ways such as if using date constraints.  Such model can be transferred to other software that would yield different leveled schedule if these links are not transferred. It will not tell the whole story about delay reason but will still be very useful. 

I use the date constraints method to freeze resource leveling done by other software, this can be used to verify if the resource leveling is feasible.  Please be aware not all software yield reliable resource leveling output, not common but happens.

http://www.planningplanet.com/forums/asta-powerproject/576477/asta-pp-resource-usage-plan

I would like to see delay reason shows delay as it currently does and not miss any resource, including materials and financial and that all delayed activities due to resource leveling are included.  This without any mention of resource dependencies as this would be ambiguous.  The delay duration or perhaps a date should be enough for the scheduler to pinpoint and investigate complex delay reasons.

I don't understand why did you write that no reason for activity 4 delay is shown.

There is resource link from activity 1 to activity 4. I understand that it is not sufficient for starting both activities 3 and 4 in parallel.

Vladimir,

dates do not show why an activity is delayed

Of course not, same as delay duration does not tell why an activity is delayed.  Duration is based on some calendar while a date of delay start can be as useful. I can live with only the delay duration.  I am happy with how delay reason is supposed to work but there are some misses, to my surprise some delayed activities show no delay reason this should be esy to fix but I would like to see when delay reason was due to materials of financial constraints.

For the purpose of creating the snapshot schedule better keep the compromise, just keep reminding users that there is a pragmatic compromise. 

Best Regards,

Rafael

Yes - There is resource link from activity 1 to activity 4.

But Reason of delay column for Activity 4 is empty.  I expect it to show Resource A 7 days without specifiyng if because of Activity 1 or 2, both caused the overload prior to leveling.  In other words same reason as that shown for Activity 3.

 we have not these problems here.

If the change of construction sequence is reasonable and does not endanger reaching contractual milestones successfully Owners do not object. But contractors are responsible for meeting major milestone dates and so they shall not agree with dates that are not achievable.

In the following scenario "Reason of delay" misses to mention there are two driving links, this is misleading.  Better say reason of delay is a predecessor link, then by looking at other reports the scheduler should be able to identify all activity links that caused the delay.

Date constraints should also be included as these can delay an activity.

All activities are placed somewhere in the schedule, if the “Reason of delay” is empty, something is missing.

What can be a “Reason of delay”?

1. Actual Start.
2. Active Driving link(s) [can be more than one].
3. Active Resource dependency(s) [can be more than one].
4. Active Start [NET] Date Constraint.
5. Data Date, activities not started with no active driving links, no active driving resources and no active driving Date Constraints will be placed at data date.
6. Concurrent delay reasons might occur.

Am I missing something?

Hi Rafael,

could we include, "not 24hd7dw Calendars"?

What can be a “Reason of delay”?

1. Actual Start.
2. Active Driving link(s) [can be more than one].
3. Active Resource dependency(s) [can be more than one].
4. Active Start [NET] Date Constraint.
5. Data Date, activities not started with no active driving links, no active driving resources and no active driving Date Constraints will be placed at data date.
6. Concurrent delay reasons might occur.
7. Not "24hd7dw Calendars" applied to resources or activities.

Anoon,

adjustments do not always mean violation of approved logic.

You described uncertainty that shall be considered in risk analysis.

Marcus,

Calendars will always be considered in the calculations of "links" early dates but ultimately the delay is on the driving link.  It is the driving "link" [logic-link/resource-link/date-constraint ...] what gives meaning to reason of delay.  If you tell me the delay reason is some calendar and nothing more I will be lost, but if you give me the driving "link", whatever it is, I will get it, "link" calendar will be known as well as activity and resource assignment calendars. Calendars can be omitted as a reason of delay without loss of meaning. 

Maybe the statement - "Data Date, activities not started with no active driving links, no active driving resources and no active driving Date Constraints will be placed at data date" should be changed to - "Data Date, activities not started with no active driving links, no active driving resources and no active driving Date Constraints will be placed ASAP after data date."

Maybe ALAP should also be considered a possible "Reason of delay".

Figuring out "Reason of delay" is not easy, this field has huge potential to be of high value. 

Rafael,

Considering what you said, I must agree with you, "calendars" are natural object atributes, and shuold not be considered a delay generator during the natural scheduling process, in the same way we could say that the ALAP modeling condition would also be a planning attribute, not a top reason of a delay.

Anyway, the "report of the reason of delays", is really very useful for planners.

Then what is the reason for delay for Activity 2 in following scenario?

Same as if not for ALAP?

Marcus - "we could say that the ALAP modeling condition would also be a planning attribute, not a top reason of a delay"

This might answer a question I had on my mind about showing delay reason if not for ALAP.  Your reasoning about it being an attribute at first sight looks good.

I recall an old article on 3 scheduling gurus complaining about how difficult it is to understand what is driving schedule logic, this "Reason of delay" field can help a lot.

Anoon,

I don't understand what are you trying to prove.

Of course there are uncertainties and of course they shall be taken into account when contingency reserves are calculated.

Nobody here suggest to use "Retained Logic Only".

But life is more complex than you proposed, FS only does not work in most projects and particular in the pipeline construction projects that you used as an example.

Vladimir,

Today software update shows improvements on Reason of delay, it looks like some work is in progress, I like the improvements so far, looking good, very good.

Best regards,

Rafael

Anoon,

if an activity does not start at its early start time then it is delayed for some reason. Activity delay does not necessarily means project delay. And negative float also does not mean that an activity was delayed. Maybe target date was too close or some of the previous activities took longer than expected.

I don't like and approve negative floats. Floats are used for schedule analysis and if an activity is critical in the current schedule it has zero float even if the project is late or some time constraints were not met. Spider Project calculates (but not uses) negative floats also (as a separate field) but just for the reference and for people who are used to this.

Activity resource constrained floats and resource assignment floats are not the same. Look at slides 56 and 57 of my presentation at recent Construction CPM Conference:

http://www.spiderproject.com/images/img/pdf/Construction%20CPM%20Conference%202019/Beyond%20CPM.pdf

Anoon,

looking at the Gantt Chart you may notice that some activities do not start at the early start day and may be interested why. One of the potential reason - an activity start was set as ALAP, other reasons may include the lack of required resources, materials, costs. This is what we call Delay. It does not consider due dates and so negative float does not matter.

Anoon,

ALAP (zero free float) is used when you need something to be done "Just in time".

Example: it does not make sense to deliver materials long before they are required.

Negative float is an information that helps to analyze project status but is useless for project network analysis. Even if my project is late I still need to know schedule critical path and activity floats in the current schedule calculated creating forward and backward paths from achievable dates. By Critical Path I mean Resource Critical Path, traditional Critical Path is its particular case if project resources are not limited.

Anoon,

it is obvious that it is not possible to show real life schedules in the forum discussions. So discussing scheduling problems people use examples.

Now imagine that you got following real life task:

Determine what numbers of people (of different specialities), machines and equipment you will need at the remote sites and what spreads to create for building 730 km pipeline to certain date and with other time constraints like the need to build certin parts of it at predefined small time windows?

Using more resources than necessary means additional expenses, using less resources than necessary means finish delay and potential penalties. Missing time windows mean 6 months delays.

We did this creating project model consisting of 9000 activities and optimized resource requirements using resource leveling and risk simulation. Can you suggest any other way? I don't think that superintendents look for many months ahead deciding who shall do what and in what order.

As you certainly know resources are always restricted. And the software can estimate much more options for finding the best way to do the job. But it may be useful only if it takes into account all existing constraints like do the people that make decisions. Superintendents will rely on the schedules created by the software if it takes into account everything they do. 

We met disbelief on construction sites many times but later, after system implementation, the same people told us that now they don't understand how did they work earlier.

Anoon,

when several activities require the same resource at the same time it is necessary to decide what activities to delay. Wrong decision may lead to the schedules that are longer than necessary. That is why the software looks for the decisions that minimize overall project duration. Some algorithms are based on activity floats but it is not sufficient for finding the best solution. Spider Project uses sophisticated optimization algorithms that usually create shorter schedules than created for the same projects by other software. Look at this discussion http://www.planningplanet.com/forums/planning-scheduling-programming-discussion/574396/comparison-resource-levelling-algorithms-di

So right decisions shall be based on the consequences to overall project duration and even if you assign scarce resources to activities with largest float it does not guarantee the best schedule. It is necessary to look much further than to activities competing for the same resources at current moment. That is why we need computers - to help us to take right decisions and not only to print nice reports.