Resource vs activity calendars issue

Resource vs activity calendars issue

Correct application of the Critical Path Method requires consideration of ALL constraints. A calendar is a ‘type of constraint’ that defines when work can and cannot be performed.

There are two main calendar types Activity Calendar and Resource Calendar.

Activity Calendar

Activity Calendar defines when work technically could be performed.

  • A low noise restriction
  • Production Freeze period 
  • SteerCo calendar

Resource Calendar

Resource calendar defines the availability of the assigned resource.

Part-time specialist is available 9 am – 5 pm Monday – Wednesday.

    Work could be completed when both conditions are met.

    Let’s review a simple example with one activity and one resource only:

      If a two-day activity could only be performed on weekends (Saturday & Sunday) and the assigned resource only works Fridays & Saturdays, this activity only could be performed on Saturdays. The required effort is two days, activity duration is eight days (Saturday – Saturday).

        Not all scheduling tools can simulate scenarios with different activity and resource calendars correctly.

          Microsoft Project

          Microsoft Project correctly calculates the duration, start and finish dates (Saturday to Saturday). However, in the activity Gantt chart, it is unclear on which days the work is planned (only by Saturdays, not Sunday to Friday).

            Spider Project

            Spider Project correctly calculates duration, Start and Finish dates (Saturday to Saturday). Additionally, detailed scheduling in the activity Gannt chart shows exact dates (if needed, time as well) when the task is planned to be executed (Saturday + Saturday).


              Primavera also allows having activities and resource calendars. However, it is impossible to calculate the schedule with both calendars simultaneously.
              If the activity type is specified as “Task Dependent”, the schedule incorrectly shows that the activity could be performed on Sunday and Saturday:

                If the Activity type is specified as “Resource Dependent”, the schedule incorrectly shows that the activity could be performed on Saturday and Friday.

                  Regardless of the Primavera setting, Duration, Start and Finish Dates will be incorrect.

                  In CA Clarity and Project on the Web also would not be able to simulate work for this mini-project correctly. These tools only support Resource Calendars, not activity calendars.

                  Apart from Activity and Resource Calendars project plan may require other calendar types:

                  • Project Calendar
                  • Team Calendar
                  • Shift Calendar
                  • Activity Lag Calendar


                  Alex Lyaschenko

                  PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

                  Monte Carlo Simulation challenges. Level of details challenge.

                  Monte Carlo Simulation challenges. Level of details challenge.

                  As discussed in the previous posts, applying the Monte Carlo Simulation (MCS) CORRECTLY for a large project may take many hours. As a workaround, some risk consultants recommend running simulations based on a high-level schedule, known as a control schedule and a ‘Level 3’ schedule.

                  The results of MCS performed based on the detailed schedule and high-level schedule are likely to be different, sometimes significantly different! There are a few reasons for that. In this post, we review one of them: the missing level of complexity.

                  Work packages are the smallest unit of work that a project can be broken down into when creating your Work Breakdown Structure.

                  In this post, the term ‘Work package’ (WP) represents ‘A group of activities’. It could be the smallest unit of work or a group of units.

                  When WP in a high-level schedule is represented by a single activity (or a few activities), the schedule misses a level of complexity of each WP. Without this information, the result of the simulation could be dramatically different.

                  Let’s review a simple example: A project has two WPs. Each of them has five 10-day activities, but in 1st WP all activities are consecutive, and in 2nd WP, all activities are concurrent.

                  If we decide to create a high-level schedule, we could simplify it to two linked ‘50 days’ and ‘10 days’ activities. The overall duration of both schedules and the logic between WPs will be the same.

                  Let’s assume each activity in our project has +/-2 days of uncertainty, which is +/-20%.

                  Detailed schedule with uncertainties:

                  High-Level schedule with uncertainties:

                  Now, we can calculate the probability of delivering this project in 60 days (the deterministic Most Likely scenario) and use both schedules as the base for the simulation. 

                  We are going to use a triangular distribution. As explained in the previous posts, the Beta / PERT distributions often better represent real-life probability, but they are unique to each risk analysis tool. I want to be sure that this experiment can be replicated with other risk analysis tools.

                  Also, due to the randomised nature of the Monte Carlo Simulation method, the result of any new simulation is always different. The more iterations performed, the less volatile results will be. I set the Spider Project to 50,000 iterations to minimise the volatility.

                  Project Probability Distribution

                  The performed simulation based on the High-Level schedule gives us the following probability distribution:

                  The performed simulation based on the Detail schedule gives us a different result:

                  There is 49.8% probability that this project could be completed in 60 days if the High-level schedule was used for this analysis and 29.2% probability if it was performed based on the Detail schedule.

                  However, project activities in both cases are going to be executed the same way, and the probability  should be the same. To understand such an anomaly, we need to go to the next level and analyse the probability of each WP separately.

                  1st WP probability distribution

                  The probability distribution of the first WP based on High-Level schedule:

                  The probability distribution of the first WP based on Detailed schedule:

                  Uncertainties in a sequence with ‘Finish-to-Start’ dependencies compensate for each other, so the result of the First WP simulation is roughly the same, regardless of the applied schedule. It is around 50%.

                  2nd WP probability distribution

                  As the second WP has only concurrent activities, the probability distribution curves are dramatically different.

                  Based on the Detailed schedule it is only ~3% chance that ALL activities could be completed in 10 days. If any activity is late (>10 days), the WP will be late.

                  In the High-level schedule, this level of complexity is lost, and the probability complete the WP in 10 days is 50%.

                  Probability distribution of the second WP based on the High-level schedule:  

                  Probability distribution of the second WP based on the Detailed schedule

                  There is a big difference between 3% and 50%! Depending on which result is presented to project decision-makers, it may lead to different actions.

                  Level of complexity

                  The analysed example above may look extraordinary. Not all projects have five linked concurrent activities. However, if we analyse any schedule, we are likely to find that there are days with more than five planned activities. All these activities are logically linked via direct or indirect logic. If these activities have large Total Floats, the effect of uncertainties should be immaterial. However, if they are on a project critical path or near a critical path, the effect will likely be noticeable.

                  Without Quantitative Risk Analysis (QRA), it may not be possible to understand the effect of uncertainties on project delivery dates.

                  Logic in real-life schedules is much more complex. WPs have other than ‘Finish-to-Start’ types of dependencies, technical and resource constraints, activity and resource calendars, lags and leads. These factors impact the level of complexity of each WP.

                  Also, logic between WPs is more complex than just a ‘Finish-to-Start’ dependency between the last activity in one WP and the first activity in another WP. On top of this, there could be more than one dependency between WPs, and these dependencies could be somewhere inside each WP, not between the end and start points:

                  Example of complex logic between WPs

                  The volatility of Critical Path

                  Another challenge is to demonstrate a Critical Path in a high-level schedule. A WP may or may not be on a critical path. If it is, it doesn’t mean that all activities in the WP are critical. The critical activities in the WP could be somewhere inside of WP. There also could be many critical fragments.

                  A scheduler may summarise critical and not critical activities in a high-level schedule. Unfortunately, there is no guarantee that the critical path is going to be stable during the life of the project. The volatility of the critical path means that a high-level schedule has to be constantly redeveloped.

                  Detailed Schedule

                  The described challenge is relevant to detailed schedules, not just to Control schedules.

                  There are no commonly accepted rules that define the correct level of detail for each schedule. While there are some recommendations, practically the level of detail depends on portfolio standards, the experience of the master schedule, the capacity of the scheduling team, applied schedule and risk analysis tools, and some other factors.

                  Two schedules developed for the same project by two different project teams are unlikely to be identical. The difference may look immaterial but may have a significant impact to the results of Monte Carlo Simulation.

                  Schedule duration paradox

                  The probability of delivering this project based on the ‘Most Likely’ durations is only 29%. This example demonstrates ‘Schedule duration paradox’:

                  Schedule based on the most likely activity durations doesn’t have the most likely duration

                  This is one of the factors why projects are late. When project SMEs provide the ‘Most Likely’ estimations for each schedule activity, and a scheduler uses them to develop a deterministic (Critical Path Method) schedule, project stakeholders often assume that such a schedule has ‘most likely’ delivery dates. Calculated dates are used as project commitments. However, due to the complexity of logic and parallel streams, the probability of meeting these commitments is likely to be less than 50%. Sometimes significantly less.

                  Monte Carlo Simulation is one of the Quantitative Risk Analysis (QRA) methods that help to calculate achievable dates, but it has to be applied correctly. A high-level schedule doesn’t have the same level of complexity as it is in a detailed schedule. It impacts the project probabilities calculated based on the Monte Carlo Simulation method. The difference could be sufficient to drive the project in the wrong direction.

                  There are many other important MCS challenges. I will continue “unwrapping” them one by one in my future posts.

                  Alex Lyaschenko

                  PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma