Schedule Quality Metrics. Invalid Dates.

Schedule Quality Metrics. Invalid Dates.

by | 1 Aug, 2022 | Blog

One of the important questions, when a schedule quality analysis is performed, is: “Is the schedule review up-to-date?”. There are a few metrics that could help find the answer to this question and identify activities with potentially invalid dates. Some of them could be performed based on the current schedule and others require a comparison to the previous schedule snapshot. Identified issues may indicate that project has gaps in a schedule maintenance process that must be addressed.

Completed, in-Progress and Not Started activities

The status of each activity is defined by Project status date (data date), Start & Finish dates and ‘% Complete’. There is a correlation between these data points.

Incomplete activities in the past.

All activities with start and/or finish dates in the past have to be actualised (100% complete) or rescheduled.

Started or Completed activities in the future.

All activities with actual dates in the future have to be unactualised (0% if not Started and <100% if In-Progress) or actualised dates updated to the past.

Activates with a start date in the past and finish in the future but with 0% or 100% of progress.

In-progress activities have to have the start date in the past, the finish in the future, and ‘% Complete’ between 0% and 100%. All In-progress activities with 100% or 0% of Completion have to be reviewed. Dates or ‘% Complete’ need to be updated.

Incorrect Status of Milestones

When a milestone indicates completion of the event, the milestone has only to be marked as “Completed” when all predecessor activities are completed and, on the opposite, if all predecessors are completed, the milestone has to have a “100% Complete” status.

Actualised milestones with open predecessors.

Completed milestones with the “Not Completed” predecessor(s).

The status of the milestone and the status of predecessor activities have to be reviewed and updated.
This issue may indicate that the milestone has a strict dependency that must be removed.

Not Completed milestones with complete predecessors.

Not Completed milestones with ALL Completed predecessors.

This issue indicates that the schedule may have missing activities or dependencies.

Historical dates

Status, Start and Finish dates of already Completed activities should not change from version to version.

Unactualised activities

Activities that previously were reported as “Completed” but the status has changed to “In-progress” or “Not Started”.

Justification for each activity previously reported as completed, but not completed now must be provided.

Historical start and dates changed

Activities that previously were reported as “Completed” with changed Start and/or Finish dates.

Justification for each activity with changed actual start and/or finish dates must be provided.

The last two metrics are particularly important when a quality analysis of a contractor schedule is performed. Constant issues are a good indication that the contractor needs to mature their schedule maintenance process.

Also, projects with such issues may have a “double counting” issue when the same activity (or deliverable) is counted as being completed a number of times.  

Schedule Guidelines

GAO Schedule Assessment Guide, Planning & Scheduling Excellence Guide (DCMA-14) and NASA Schedule Management Handbook have metrics to identify invalid dates but they include only metrics to identify invalid activities in the past and the future, the first two checks in this post.

Schedule Tools

There is a philosophical question what to do when a schedule status update is not received?
Should a project team assume that all activities in past have not been started (or completed) and automatically push the activities to the earliest possible date: Project Status Update (known as Data Date) or they should assume that some of them may have started (or Completed) and not be updated dates until the clarification is received?
Probably developers of scheduling tools have different views on what is the correct answer to this question.
Primavera and Spider Project have the “Data Date” feature to automatically push activities with dates in the past to the Data date. Microsoft Project doesn’t have a such feature. In my observation, projects managed in Microsoft Project more often have “Incomplete activities in the past” issues and projects that are managed in Primavera more often have “Historical start and dates changed” issues.

Alex Lyaschenko

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

Implementation of the Critical Path Methods in Different Scheduling Tools

Implementation of the Critical Path Methods in Different Scheduling Tools

by | 27 Jul, 2022 | Blog

Would the project dates calculated based on the critical path method be the same regardless of the applied scheduling tool? Not always!!!

Some time ago one large Telco company in Australia decided to replace their existing PPM system with ‘CA Clarity’. Clarity already was implemented in the organisation but used only as a corporate timesheeting system. The previous custom-made PPM system allowed to import Microsoft Project schedules and automatically retrieve dates for project status reports.

Clarity has integration with Microsoft Project, so the tool looked like a good alternative to the old PPM system. The portfolio initiated a project, which was a big disaster. The project manager made a dangerous assumption: “As both tools are based on the Critical Path Method, the schedules calculated in these tools are going to have the same dates”.

This was not the case. Imported and recalculated schedules had different delivery dates!!! The reality was even worse: the schedule imported back to Microsoft Project had different dates compared to the original schedule developed in Microsoft Project, even if the schedule was recalculated in Microsoft Project again!

In theory, the Critical Path Method is a well-defined method and a schedule calculated in any scheduling tool that supports this method should be the same.

In practice, projects consist of components: activities, calendars, constraints, dependencies, lags, resources, etc.

Scheduling tools have different features to manage and integrate project components. The way these features are implemented impacts the Critical Path Calculation.

When a schedule is imported between the tools some information could be completely lost as the new tool doesn’t have data fields to store this information.

In the described example, at that time (not sure if it is still the case) Clarity supported only resource calendars, not activity calendars. So, during the import, the information in activity calendars was lost and when the schedule was imported back to Microsoft Project, the project dates were different. Later, when I supported one of the Australian banks to intergrade Microsoft Project and Clarity, I found other differences between systems that impact schedule calculation.

Primavera, Microsoft Project, Spider Project and other project management tools support the critical path method they have unique features. The way these features are implemented may impact the Critical Path calculation!

Some examples of such features:

  • Primavera supports more than one dependency between the activities, and Microsoft Project doesn’t;
  • ‘Deadline’ in Microsoft Project impact Total Float calculation, Primavera doesn’t store ‘Deadline’ dates;
  • Primavera and Microsoft Project have different types of activity constraints;
  • Microsoft Project supports ‘% duration lags’, and Primavera doesn’t;
  • Spider Project takes into the calculation activity AND resource calendars, Primavera activity OR resource calendars;
  • Spider Project supports ‘Volume’ and ‘Duration’ types of activity, Primavera and Microsoft Project support only ‘Duration’ type;
  • Microsoft Project allows to link activities and summary tasks (WBS), Primavera only creat links between activities;
  • Primavera and Microsoft Project support Levell of Effort / Hammack activities, but this feature is implemented in a totally different way;
  • Primavera support the ‘WBS Summary’ type of activity, and Microsoft Project doesn’t;
  • Spider Project supports ‘Conditional’ scheduling, Primavera and Microsoft Project don’t.

Principles of the Critical Path Method could be explained based on a small simple schedule and calculation of such schedule in any scheduling tool should give the same result.

Real-life projects are much more complex. They have different calendars, hard and soft constraints, lags and leads, other than ‘Finish to Start type’ types of dependencies, etc. Implementation of these features impacts the way the critical path is calculated.

Some scheduling tools have methodological issues. Project’s real-life scenarios could not be properly simulated due to technical constraints. It is important to learn these constraints, find work-arounds or maybe replace the tool.

Alex Lyaschenko

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

Monte Carlo Simulation Challenges. Data collection Challenge.

Monte Carlo Simulation Challenges. Data collection Challenge.

by | 15 Jul, 2022 | Blog

Terminology

What do the terms optimistic, pessimistic, and most likely really mean?
Because they are very different for different people, when one estimator says pessimistic, that person is thinking the technology might prove to be a bit more difficult than expected and thus take 10% longer. Another person in the team may assume that ‘pessimistic’ means that the work might be interrupted by an earthquake, tsunami, and nuclear meltdown simultaneously (even if it has not happened in the past).

Data Collection

Popular scheduling tools, like Microsoft Project and Primavera, don’t have native features to capture ‘3 points estimations’, so planners usually don’t capture estimations provided by Subject Matter Experts. A risk manager or a scheduler applies a range based on a single deterministic estimation instead. This approach is based on two dangerous assumptions:

      • All provided estimations are “Most Likely” estimations.

When SMEs are forced to provide a single estimation, they have to decide on how much contingency to include in the estimation. Some estimations in schedules have “optimism bias”, others, on the opposite, are too conservative.

      •  All activities have the same level of uncertainty.

There are many reasons why some of the activities may have dramatically different uncertainties: new technology, new equipment, new contractor, etc.  

Probabilistic scheduling tools, in the opposite, give an opportunity to capture activity durations as ‘3-point estimations’. Spider Project, arguably, the most advanced project delivery tool gives the opportunity to capture any type of initial data as 3 points: durations, cost, volume of work, resource productivity, lags, etc.

 Primavera and Microsoft project have custom fields that could be used to capture at least the duration of activities. Then weighted durations could be calculated. Both tools have built-in formulas. PERT or any other method could be applied for that.

Microsoft Project used to have built-in 3 points estimation fields but it’s current version doesn’t have this feature any more.

Objective vs Subjective

The Monte Carlo method works well when a lot of historical data is available. Unfortunately, the unique nature of projects means that likely historical data is going to be limited. However, even a small volume of historical data could be beneficial and portfolios have to implement methods to collect historical project data in a systemic way.  

 When historical data is not available the only way to collect estimations is to interview Subject Matter Experts (SME) and collect subjective information. However, it needs to be done in a smart way.

 It’s always better to ask a SME to provide an optimistic estimation first. Then ask the interviewee to think about the worst-case scenario and only after that provide the most likely estimation.

The trick is when the interviewee thinks about different possibilities, the most probable estimation is likely to be more accurate.

Hidden Risks

I found it extremely useful to collect data as a range even though I am not going to use it for Quantitative Risk analysis. It actually doesn’t take much longer to do so but gives me an opportunity to identify hidden risks. After all estimations are collected, some activities may have an abnormal range, comparing to the rest of the activities. It’s worth discovering the underlying reasons as there is often a story behind each abnormal range. Some of these stories get converted into risks or even issues.

Alex Lyaschenko

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

Schedule Quality Checks. Lags and Leads

Schedule Quality Checks. Lags and Leads

by | 29 Jun, 2022 | Blog

We already discussed two types of schedule quality metrics: Missing Dependencies and Activity Constraints. Another important area to control is activity lags and leads.

A project delivery schedule must reflect real-life processes and the way how the work is going to be performed. Often processes include essential shifts between parallel or sequenced activities. The shift between activities is called dependency ‘Lag’ or ‘Lead’.

Lag is the amount of wait time between commencement and completion points of different activities.

Lead is the amount of acceleration time between commencement and completion points of different activities.

In simple words, a Lead is a negative Lag.

Is it good or bad to have Lags in the schedule?

Activity lags and leads are extremely important as they allow to optimise project delivery by performing tasks in parallel or overlapping activities. Project managers need to look at any opportunity to use lags and leads in their schedules.

It is hard to imagine a DELIVERY schedule without Lags. If a schedule doesn’t contain any lags, it is a good indicator that potentially the schedule is not used for delivery, only for reporting.

Also, there are many situations when dependencies with leads may require. It could a contractual obligation or ATAP (As Timely As Possible) scenario.

Example: The contract states that the Notification needs to be issued 30 days prior to the completion of construction.

However, lags/leads require special attention for a number of reasons:

  • They could be used to hide contingency or delay;
  • Some scheduling systems (like Primavera and Microsoft Project) don’t provide front-end access to the dependency table and lack features to control dependencies with Lags. It adds significant schedule risk to a project.

So,

  • All lags must be explained. Only authorised and accepted lags should be in a schedule;
  • Clear process has to be established to manage dependencies with lags.

The Schedule quality assessment has to include metrics to control lags and leads.

Before reviewing the Lag metrics, let’s understand how lags work in real life and how scheduling tools could help us to simulate work with dependency lags.

    Lags & Leads

    There are 4 main types of dependencies and scheduling tools that allow each of them to have a lag or a lead. It gives us 8 possible theoretical scenarios of application lag/leads in a schedule.

    However, not all of these scenarios are actually valid scenarios.

    For example: ‘SS – 5 days’ scenario has a logical conflict. On one hand we said that the successor can only start after the predecessor has started. On another hand, we said that the successor can start before the predecessor.

    These scenarios have to be eliminated from the schedule. In this case a schedule quality metric to identify such scenarios becomes very handy.

    Time and Volume Lags

    By nature, there are two types of lags in projects: Time Lags and Volume Lags.
    Time lags are required when by PROCESS, there is a requirement to have a “wait” TIME between activities.

    Volume lags are required when by PROCESS, a successor activity could commence only after the required volume of work of the predecessor is achieved.

    When ‘volume lag’ is presented by ‘time lag’ it may create an unexpected issue. If the predecessor activity has started but didn’t progress as planned (and the minimum required volume is not achieved), the schedule will incorrectly show that the successor activity already could commence.

    Lag Calendars

    The duration of a ‘Time Lag’ depends on the applied calendar.

    Example:

    A 24h lag may mean 1 day with 24*7 calendar and 3 days with 8*5 calendar.

    A lag may have a different calendar from predecessor and successor activities calendars.

    Example:

    Home Renovation project requires to deliver the heavy sofa to a room, after paining of all walls in this room is completed

    • The painting could be performed between 5pm-10 pm (Mon – Sat);
    • The Delivery is only possible between 8am – 12pm (Mon – Fri);
    • It is technically required 16 hours the painting to dry;

    In a schedule, it is going to be “FS+16 hours” dependency, but the predecessor, the successor and the lag calendars are going to be different.

    It is hard to simulate such a scenario in Microsoft Project or Primavera. Below we will review a potential workaround.

    Lags in Scheduling Systems

    Scheduling systems have different levels of maturity and features to manage lag.

     

    Primavera

    Primavera doesn’t support Volume lags and offers four options to manage lag calendars.

     

     

    • Predecessor Activity Calendar,
    • Successor Activity Calendar,
    • 24-Hour Calendar, and
    • Project Default Calendar.

     

    For whatever reason, lag calendars setup has to be done in the ‘Schedule option’ dialogue window. It is a Project characteristic that has to be defined prior the schedule development being commenced, not during the calculation.

    • Unfortunately, users have to choose one of the options that will be applied to the whole schedule. It is not possible to apply a predecessor calendar lag in one part of the schedule and a successor calendar lag in another part of the schedule;
    • When the external schedule is analysed, it is important to know which setting in Primavera was used by the external party. Changes in this setting may result in different activity start and finish dates and even change the Project Critical Path;
    • Primavera users must be extremely careful when opening multiple projects as the Lag Calendar option could be different for each project. This is because all the project options are changed permanently to be the same as the Default Project and therefore some of your projects may not calculate the same way as they did before opening the projects together;
    • Primavera doesn’t provide front-end access to the dependency table and makes it extremely hard to control dependencies with lag and leads. There is possible to generate a report of activities with dependency lags but then users have to manually find and review each activity one by one.

    Microsoft Project

    Microsoft Project doesn’t support Volume lags and doesn’t provide options to manage lag calendars. The lag duration is always calculated on the successor calendar.

    Microsoft Project offers the users an opportunity to use % Time lags. While it may sound like a good workaround to a volume lag, users have to be extremely careful with using this feature. The tool calculates the duration of ‘% lag ’ in a very unusual way. They use a predecessor duration in hours as a 100% base but apply a successor calendar to calculate the actual duration of the lag.

     

    Example:  

    The ‘Activity A’ has the standard (8h*5d) calendar and the ‘Activity B’ has 24 hours calendar. These two activities have SS+50% dependency: 

    It is hard to understand why the lag has the 2 days of duration as it is shown in the ‘Start’ column and the Gannt Chart: 50% of the ‘Activity A’ is 5 days and 50% of the ‘Activity B’ is 24 hours. None of these options gives us 2 days!

    In this case, Microsoft Project calculates the dependency lag as:

    • 50% of predecessor duration in hours: 8h * 10d *50% = 40 hours
    • 24 hours calendar from the successor applied: 16 hours 27/06 (the successor starts at 8am) + 24 hours 28/06. So, the ‘Activity B’ starts at 12am 29/06:

     

    I think it is very confusing and applicable to real-life scenarios only when predecessor, successor and lag calendars are the same.

    Spider Project

    Spider Project supports Time and Volume Lags and allows specifying a calendar for each lag.

    Spider Project provides front-end access to the dependency table including lags attributes and notes.

    Users can add a note that explains the reason for each Lag and identifies changes in lags by adding a column ‘Lag difference from compared schedule’ and applying a filter in the table. 

    Additionally, when Spider Project users apply a filter in the dependency table, the filtered dependencies could be reflected in the Gantt Chart view. For example, a user may want to show only activities with changed lags.

    Schedule Export Issue

    The misalignment in approaches to managing lag calendars in different scheduling tools creates a massive issue when a schedule needs to be exported from one tool to another.
    This is one of the examples of such an issue:

    https://support.oracle.com/knowledge/Oracle%20Cloud/2513929_1.html

    I can offer a workaround, for both Primavera and Microsoft Project users to apply lag calendars correctly. If between predecessor and successor add a technical milestone, it would be possible to specify the milestone’s calendar that represents the lag calendar.

    This workaround should solve the lag calendar issue but adds unnecessary complexity to the schedule and hopefully one day Oracle and Microsoft can add lag calendars to their scheduling tools as already realised in Spider Project.

     

    Points to consider

    • Leads require special attention as in some cases it may result in a reverse logic when a successor activity requires to start (or even finish) before the predecessor activity commenced. 
    • It is possible but not easy to find dependency Lags in Primavera and Microsoft Project schedules. The general consensus of Primavera and Microsoft Project experts is that the use of relationship lag should be minimal if it’s used at all. Such suggestions solve the control issue but limit projects to simulate work as it is going to be performed in real life. Other consultants proposed workarounds to identify activity with lags via reports:

    https://projectcontrolsonline.com/blogs/74-how-to-find-relationship-lag-in-primavera-p6/676-how-to-find-relationship-lag-in-primavera-p6

    Reports are useful but still require a lot of effort. Based on the report users still need to identify each activity manually in the schedule, one by one.  

     

    Replacing lags and Leads with activities

    Another workaround recommended by consultants is replacing Lags/Leads with activities.

    This might be not a bad idea, but it is important to understand that such an approach solves one problem and creates many others. Lags, compared to activities, don’t represent project work, they don’t have associated costs or resources, and should be excluded from project performance. This workaround may impact the calculation of project progress and EVM metrics. It is hard to distinguish real activities from ‘lag activities’. Additionally, this approach required changes to other schedule quality metrics, (‘activities without resources’ as an example).

     

    How to use an activity instead of lead?

    Leads could be replaced by activities through the way of creating a ‘lead activity’ with FF dependency to the predecessor and SS dependency to the successor.

    DCMA 14 Points Schedule Assessment Lead/Lag metrics

    DCMA 14 points Schedule Assessment includes two metrics to control lag and leads.

    Metric 2: Lead
    The DCMA requires no leads (0%) to be used in the schedule.

    Metric 3: Lags
    Total number of activities with lags should not exceed 5% of the activities within the schedule.

    As described above there is very beneficial to use lags and leads as it may help to shorter project delivery. The number of lags/leads in the schedule depends on the nature of the project. 5% is just an indicator to review schedule closely but not an automatic schedule quality issue. I would recommend planners and schedules learn how to control lags and leads, instead of restricting them in the schedule.

    Filters

    It is possible to build a filter to identify activities with predecessor (or successor) “lag” (or lead) in Microsoft Project, but not in Primavera.

     

    Activities with Lags (MS Project)

     

    Activities with Leads (MS Project)

    The ‘Predecessor’ and ‘Predecessor Details’ columns in Primavera don’t show the plus (“+”) symbol for lags. The minus symbol (“-“) for leads is shown, but Primavera in these columns shows activity code (Not activity ID), and the code may contain the minus “-“ symbol.

    Alex Lyaschenko

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

    Monte Carlo Simulation Challenges. Simplicity Challenge.

    Monte Carlo Simulation Challenges. Simplicity Challenge.

    by | 19 Jun, 2022 | Blog

    Before we start our review of Monte Carlo Simulation (MCS) Challenges, we have to clarify what MCS is and how it is applied in project management.

    Monte Carlo Simulation Method

    A Monte Carlo Simulation is a model used to predict the probability of different outcomes when the intervention of random variables is present. Monte Carlo simulations help to explain the impact of risk and uncertainty in prediction and forecasting models.

    To be useful a model has to be dynamic and represent the true relationships between inputs and outputs.

    In the project management model, inputs and outputs are:

    Model

    Project Delivery Plan used a model for project planning and delivery.

    I don’t like the term “schedule” in the context of MCS. For many project practitioners, this term is associated with Time management and it is only one component of project delivery.

    Inputs

    Apart from the Golden Triangle, which includes:

    • Scope
    • Time
    • Cost

    a project delivery plan also integrates:

    • Risks (including uncertainties)
    • Resources (People, Equipment & Materials)
    • Benefits

    Full integration means that changes in one parameter are reflected in other parameters.

    Outputs

    A Monte Carlo Simulation is performed to identify: 

    • Project risks that require maximum attention
    • Project targets that can be met with sufficient probabilities
    • Contingency reserves that must be created to meet project targets
    • Current probabilities of meeting project targets
    • Resources required for the reliable achievement of project targets
    • Project activities that require maximum attention

    MCS is only one of the methods of Quantitative Risk Analysis (QRA). In this and future posts, if not specified, under QRA I mean the MCS method. If there is any interest, we can discuss other QRA methods later.

    Monte Carlo Simulation Process

    In project management Monte Carlo Simulation works the following way:

    1. Integrated logically driven Project Delivery Plan developed and assessed.
    2. People enter three estimates of initial data that are uncertain (optimistic, most probable and pessimistic) and define what probability distribution each uncertain parameter has.
    3. Risk events are included in the project risk model with their probabilities and impacts.
    4. The software calculates the model and accompanying parameters over and over, each time using a different set of initial data in accordance with their probability distributions. The number of iterations is usually defined by the risk management software user. Usually, this number is measured in thousands of distributions.

    As the result, we get the distributions of possible outcome values.

    This process has one important missing step: “Add corresponding corrective actions”. We will cover it later in a separate post.

    Simplicity Challenge

    Any process may look simple at a high level but to get the desired result detailed instructions, tools and practice are often required. Everyone, who tried to cook knows that cooking is more complex than “Prepare ingredients, mix them, apply temperature processing, and serve”. So, why do we accept the idea that the application of the scientific method in complex and complicated environments could be as simple as: “Prepare model and estimations, add risks and uncertainties, simulate, and report”? There are a few reasons for that:

    1. A burned dish can damage a planned dinner and the reputation of the chef, but decisions made based on misleading project risk analysis are likely to impact someone else, not the person who runs the analysis, or even a project manager who is responsible for project delivery.

    So many times we have been told that communication skill is the most important skill in project management. Now we have many project managers that could perfectly explain why their project is late and over budget, but don’t know how to develop an optimised project delivery plan and run quantitative risk analysis. Adding even a small financial incentive based on achieved results would motivate project managers to learn advanced project management methods, including MCS

    Another problem is a disconnect between time, cost and benefits. Until project delivery plans will not have integrated with planned benefits, this challenge will always be there. Such integration helps to drive project decisions and understand how these decisions impact outcomes and benefits, not just time and cost. MCS also could be used to calculate the distribution of financial (NVP & ROI) and non-financial metrics.

    An example of this kind of integration was discussed in this post:

    https://saluteenterprises.com.au/project-success-criteria/

    2. If companies that promote their MCS tool or QRA training say that MCS requires many hours of effort, no one will buy their tool or service.

    There are four levels in the Conscious Competence Learning Matrix and companies that promote the MCS methods can help us with moving from ‘Unconscious Incompetent’ to ‘Conscious Incompetent’, but reaching the next, ‘Conscious Competent’ level will require much more effort to grow deep knowledge of how the MCS method works, how to develop a reliable project delivery plan and which features in risk analysis tools are important.

    3. Popularity of QRA is growing. More and more companies and projects include requirements to run QRA periodically and even specify that it must be done with the MCS method. Unfortunately, well too often the QRA is performed only to “tick the box” and the result of the QRA doesn’t drive any project decisions.

    There is a simple test to identify misuse of the MCS method. Ask the Project Manager about the current probabilities of meeting project targets, which is one of the outputs of the MCS process.

    4. Precision creates an illusion of accurate estimation. MCS is a perfect tool to play a guesstimation game.

    A knife could be used to cut cooking ingredients or as a weapon. MCS is also used to justify desired or already made decisions, not to calculate required contingencies and identify critical risks and activities. In that case, it is not critical if the MCS method was applied correctly or not, and which tool was used for the simulation.

    The market is full of Monte Carlo Simulation software that primarily serves this purpose. The ability to generate colourful reports seems to be the most critical feature of this tool. If your project or portfolio runs MCS to satisfy someone’s need to say that the analysis is performed or it is performed to justify the desired decision, you may not worry about other MCS challenges.

    On the other hand, for business owners and accountable project managers, the ability to run their own independent project quantitative risk analysis based on a reliable model and risk analysis tool can save money, reputation and even lives. ‘Covid-19’ projects are a great example of it.

    Inaccurate or Misleading?

    Ones Niels Bohr, the Nobel laureate in Physics and a father of the atomic model, said: “It is difficult to make predictions, especially about the future”. Any project model is just a proxy and the result of risk analysis never could be precisely accurate. So, why are we still trying to make predictions then? Because even not 100% accurate forecasts still could be used for our decisions! However, misleading forecasts are dangerous, as they drive wrong decisions.

    The challenge is to understand where to draw a line between “inaccurate” and “misleading” when MCS analysis is performed.

    Probably you have already heard the famous quote of George Box: “All models are wrong, but some models are useful”. I prefer the full version:

    All models are wrong, but some models are useful. So, the question you need to ask is not ‘Is the model true?’ (it never is) but ‘Is the model good enough for this particular application?’

    In the application of project management, we can rephrase it as:

    “Is the Project Delivery Plan good enough to explain the impact of risks and uncertainties by applying the Monte Carlo Simulation method correctly?”

    In the series of future posts, we will try to find the answer to this question.

    Alex Lyaschenko

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