Productivity Periods and Percentage change of assigmnet

Perfect!

Got it:

Hoover image and zoom.

https://www.mediafire.com/file/szj2xmxd0r657pv/Productivity-01A.001.spr…

Rafael,

this we do not model yet. If crew composition is different at different periods your approach is the best.

But I recommend to include in the crews dummy resource that has calendar of the certain period and do not duplicate resources (summer, winter). This way everything will remain as in your example but you will get right reports on resource usage, avoid problems with resource levelling, etc. Resources in summer and winter shifts are the same.

Vladimir,

Productivity Periods work as expected but I am still struggling with the requirement for the winter and summer crews be different, in particular laborer (4 vs 3) and ripper quantities (not required vs 1). It is not only about work hours and production rates but also about crew composition. I am missing something?

Best Regards,

Rafael

Thanks, as always it is a joy to debate with Vladimir and Bogdan.

Vladimir,

Thanks, it works as expected. For my future reference I am making some changes to the resource and calendars.

I am investigating the productivity periods table and after sorted to my liking looks good but still wondering about the range of periods shown, it is not infinite, it is not limited to schedule duration but longer, some lookahead is welcomed.

Excellent!

Best Regards,

Rafael

Rafael,

like in calendar exceptions, periods of different productivities can be repeated each year (like in your example) or each month, each week, each day, etc. If you will change the data date to later year they must still work.

Productivity Periods Reference-book can be applied to any project. Just keep activity and resource types stable.

Rafael,

these are your project and corresponding reference-book with the use of productivity periods and different calendars at different periods.

https://www.mediafire.com/file/pzg1ptmom3xcbti/Productivity-01A.002.spr…

https://www.mediafire.com/file/zc7f0tvr8t862lu/Productivity_Periods.001…

Vladimir,

Done.

Rafael

Rafael,

I downloaded your file.

Please install the latest version of Spider Project. Our file formays must be compatible.

Construction scheduling usually requires one screen for the schedule and another screen for the site drawings, estimate worksheet, soil report and other contract documents such as special conditions and minutes of meetings with the client.

Maximum sanitary manhole distance is about 400-ft or 122-lm; we schedule activities for trench and pipe installation segment in between manholes, sometimes several segments can be worked at the same time, other times strict sequence must be followed. A drop manhole can suddenly change the excavation depth.

Vladimir,

I will try my sample schedule with your suggestions, is only 3 activities:

You can download the file from the following link, I might need your assistance.

https://www.mediafire.com/file/szj2xmxd0r657pv/Productivity-01A.001.spr…

Best Regards,

Rafael

Rafael, different calendars at different periods are modelled by exceptions in the original calendar.

You can easily set different resource productivities at different periods for any type of work, create corresponding reference-book, and apply it to any project.

We recommend to create different activities for working with different soil.

Vladimir,

A single resource might be able to work 8 hr/day during summer but 6 hr/day during winter. That means two calendars for the same resource. As an activity moves so his work hours. In this context compatible means no calendars overlapping.

Maybe the use of calendar exceptions can do it but it will lack some transparency. Anyway we should expect different productivities along different seasons.

Spider Project can account for financial constraints in Scheduling, nothing else can do it. Cost components along with cost centers are essential. Cost centers are only available within Spider Project.

Best Regards,

Rafael

Rafael,

please explain what did you mean by:

• Unfortunatelly Scheduling software cannot recognize multiple compatible calendars (without overlapping) for a resource while in real life this is not uncommon.

You remember that in Spider Project it is possible to create any number of WBS for the same project.

One of them can group activities by their cost codes. But still it is necessary to enter actual data for each activity to be able to reschedule the remaining activities.

Spider Project does not replace accounting system but permits to plan and to forecast future expenses for overall cost, any cost components, cost codes, departments, etc. It can also plan and track parallel budgets (like contract costs and expenses). But for this it is necessary to update project schedule on activity level, not just on cost code level.

Meeting resource calendars and activity calendar will determine when activity might happen along with logic and other constraints. Usually, equipment is available 24-7 except those with regular maintenance schedules.

I believe whatever enhance is added it shall not interfere with good resource leveling otherwise it is better to keep using workarounds that will make it.

With regard to actual hours and volumes of work, at home actual hours and volumes of work are not entered at the activity level, too granular and of not much use to us.

• We use cost codes to enter cost and work hours in our accounting system.
• For labor hours we use time cards we enter weekly for payroll with labor hours distributed per day for each cost code. Overtime and labor burden is calculated by the system.
• Weekly we issue a weekly production report for each cost code.
• Cost codes for repetitive process across many activities we find useful, so our cost system is essentially a multiple processes costing. Say we have 100 housing units, with a cement plaster activity per housing unit, we use a single cost code for cement plaster process. If there are several unit models it can be each model will have different cement plaster volumes but a simple table will give us the information to report actual production.

What was useful for decades is becoming extinct in accounting software. Maybe those who develop accounting software no longer understand how for many decades it was done and all they know is activity based costing. Perhaps it is due to the insistence of using the scheduling software for costing, software that misses good unit costing. I know of no single scheduling software with good unit costing functionality including Spider Project. Even if such thing exists it will be no match to Spider Project scheduling functionality.

Rafael,

If some resource can work in multiple shifts its calendar must include all hours or just 24 hours per day.

Please explain if I did not understand the problem.

I made an adjustment to my posting of Thu, 2023-10-05 18:22 to show I still have a preference on assigning Production Rate at the Crew/(Multi-Resource) level.

In many cases Period Productivity will not be enough and shift sheduling will make it. The Teams can have different composition, the teams can work on different hours, different seasonal resource availability is not uncommon and there is no need for Dummy Resources but team resources with the right availability, calendar and exceptions.

It is just shifts scheduling as usual, but the shifts are seasonal instead of the traditional day and night shifts, no big deal.

The basic methodology is based on creating a calendar for each shift. If same resource is to have multiple shifts then multiple resources and shift calendars will be needed to represent it. Just make sure there is no overlap.

• Unfortunatelly Scheduling software cannot recognize multiple compatible calendars (without overlapping) for a resource while in real life this is not uncommon.

Best Regards,

Rafael

Vladimir,

Thank you very much. But using shift calendars to mimic production periods seems to me more transparent and flexible.

I still have a preference on assigning Production Rate at the Crew(Multi-Resource) level.

In many cases Period Productivity will not be enough and shift sheduling will make it. The Teams can have different composition, the teams can work on different hours, different seasonal resource availability is not uncommon and there is no need for Dummy Resources but team resources with the right availability, calendar and exceptions.

Best Regards,

Rafael

Bodgan, in a similar way I use hammocks and dummy resources to get diagrams and reports for spatial resources.

Best Regards, Rafael

Productivity Periods are date fixed, I do not believe they will model the infamous Learning Curve. Activities can move and so the learning curve. And yes, if using skills and crew changes learning curve might start again. But contractors do not keep data on the learning curve for each construction activity. In any case the following reference might be of interest, it is complicated. Our hands down approach is to use average unless the duration is short, if short I suppose an educated guess might be used, but almost always we use averages.

Learning Curve Effect on Project Scheduling - 1-s2.0-S1877705816339376-main.pdf

Rafael,

download the latest version.

You will find three fields for resource assignment productivity that can be shown in the Gantt Chart columns:

1) Productivity - set manually as default,

2) Productivity (current) - at the project data date,

3) Productivity (start) - at the assignment (activity) start.

I find shown Production/hr misleading. Some formula is missing and perhaps a marker to let the user know Productivity Periods are assigned. In the following example the driving Dummy resource is scheduled to work in two Productivity Periods.

Thanks Bodgan,

I know of this workaround, but my point is why not place the production rate where it belongs. If Spider need the workaround it should be done on the background without user resorting to this workaraound. I will keep placing the production rate at the multi-resource assignment when it belong to the multi-resource and forget about "dummy productivity periods" functionality.

Best Regards, Rafael

I am watching the new functionality for productivity periods, for the moment it lacks productivity periods for multi-resources. I do not believe in a crew productivity belongs to a single resource but to the crew as a whole. As long as productivity periods is not available to multi-resources I doubt I will ever use it.

"I suppose financial resource leveling is a matter of utmost importance for government agencies that must limit the flow/timing of their projects." - not entirely true.

• Do you mean they do not always care about having the necessary financial resources on time? Are they always in the opulence? At home if they do not have the funds on time they will pay for it.

At home people enter actual work hours distributed per cost code within the payroll, we have reliable resource hours per cost code, we are not guessing how many of each code per activity. Every single minute that goes into payroll is accounted for.

For materials, subcontracts and other costs we distribute expenditures by cost code, never go down to the activity level.

We report actual production weekly, easy as we are not guessing how much per activity but per cost code. Actual cost and production data is handled by the Financial System using reliable cost, labor resource hours as well as production quantities.

The problem with tracking actual productivity exists and it is simple:

people enter actual volumes in their reports but rarely enter actual work hours that were spent on each task.

So actual productivity that is determined based on people's reports is not reliable.

We do not deppend on scheduling software for cost and production tracking but use the accounting system as aways it will be required to enter over 50% of the data in the accounting system even if not tracking production rates. The following illustration shows the most basic reports.

https://www.foundationsoft.com/learn/production-reporting-job-costing/

We do not track actual unit costs at the activity level as many activities share some or all the same cost code(s), we no not require that much detail. The same goes for production records, usually we associate production to cost codes keeping it very lean. We use same cost/production codes across al jobs, our supervisors, our accounting clerks and timekeepers within weeks memorize forever these codes.

For cash flow we use the cost coding embedded in the many software we are required by contract with our clients. Only Spider would allow us to do real financial constraints leveling but we are contractors and our contracts do not allow us to be short of funds for any individual project. I suppose financial resource leveling is a matter of utmost importance for government agencies that must limit the flow/timing of their projects.

I never liked the idea to place production rate on the resource but on the crew, in our jobs increasing the "production resource" quantity does not necesarily means a proportional increase in the crew production rate. This misconception can yield unintended results, working at the crew level helps to avoid such errors. RS Means, a well known reference in the construction industry assign production rates at the crew level an approach I always liked.

- When you click a resource line the dialog box will give you the option to assign productivity periods.

- When you click a multi-resource line the dialog box will not show an option to define productivity periods.

> I WOULD LIKE FOR THE MULTI-RESOURCE LINE TO HAVE PRODUCTIVITY PERIODS - THE IDEA IS GOOD IF ASSIGNING PRODUCTION RATES AT THE RESOURCE BUT BETTER IF AVAILABLE AT THE MULTI-RESOURCE

Best Regards, Rafael

Bogdan,

if activity Lay is shorter then its start will be delayed and FF dependency is driving. Driving dependency determines the strongest constraint on the time of activity execution.

If making Lay duration longer can shorten project duration Spider will adjust Lay activity duration decreasing assigned resources workloads.

I don't understand the problem with double Lag dependencies.

Below is an example of Dig-Lay dependencies. Lags are defined as volume %.

I created 4 dependencies between di and lay activities.

Standard SS and FF with 20% of the volume lags, and additional: 60% of Dig activity precedes to 30% of Lay activity, 80% of Dig activity precedes to 55% of Lay activity. All dependencies are taken into account when scheduling.

Bogdan,

for excavation activities we use volumes as cubic meters. We also use not only SS and FF dependencies with other activities but also Double Lag (Point to Point) dependencies if the depth is changing.

Productivity percentage change can be used for modeling increasing skills of assigned workers, as an example.