Is the Model good enough?

Is the Model good enough?

by | 15 Jun, 2025 | Blog

“All models are wrong, but some are useful” is one of the most misinterpreted quotes in project risk management. The full quote from British statistician George Box provides essential context:

“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?’”

The key message isn’t simply that simplified models have value but it’s that we must CRITICALLY assess whether a model is fit for purpose. Recognising when a model is not applicable is just as important as knowing when it is.

In the context of project risk management, this distinction is crucial. A schedule may be a sufficiently accurate model for tracking progress or managing contracts, yet fall short as a foundation for Monte Carlo Simulation analysis.

The real question the project risk community needs to address is:
“How can we develop a dynamic project delivery model that is good enough to support Monte Carlo Simulation analysis (or another quantitative risk analysis method)?”
Project data modelling (scheduling), risk simulation systems and the underlying methods must be CRITICALLY assessed for faulty assumptions, and missing or incorrectly working capabilities.

Companies that promote scheduling and risk management systems have little incentive to acknowledge or address their limitations. Their focus tends to be on marketing the strengths of their tools, not on identifying critical gaps that may impact practical use.

As a result, insufficient modelling capabilities are frequently overlooked or dismissed.
Blind trust in the project delivery model is an unnoticed delivery risk.

A community of Practice dedicated to complex project data modelling and the assessment of risk simulation systems.

Alex Lyaschenko

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

Start-to-Finish and Hammock

Start-to-Finish and Hammock

by | 30 Apr, 2025 | Blog

In a network analysis method, Start-to-Finish (SF) dependency type creates a lot of confusion and is often misused. SF logic makes a lot of sense when it is used in combination with a hammock activity.

SF dependency means a predecessor activity (A) can’t finish until a successor activity (B) starts. For example, if a project needs to move from System A to System B, they can’t stop using System A until System B is functional. They may use both systems in parallel for a while.

It means the duration of activity A can’t be fixed. If the start of activity B is delayed, the duration of A will automatically be extended. Such scenarios in the network are modelled via the hammock activity type.

Start and Finish of a hammock activity depend on other activities. So, it must have at least two predecessors. One to drive start and one to drive finish. It may not have a successor.    

Let’s review two scenarios:

  1. Activity A can finish only after Activity B starts.

If Activity C is delayed, it will push the start of Activity B. If Activity A has a fix duration, it pushes the remaining part forward and creates an artificial gap. The resource demand and costs associated with Activity B will not be simulated correctly. 

Instead, the duration of activity A must be extended depending on other activities. If Activity C takes a longer duration of Activity A needs to be automatically increased. Also, if Activity C takes less time, Activity A must start earlier, and the duration will be automatically increased. 

Changing the activity type to Hammock fixes the problem. 

2. Activity B must start before Activity A can finish.

This scenario looks similar to the first scenario. However, in this case,  Activity B depends on the progress of Activity A. Similar to the first scenario, both activities have an overlap, but this scenario is not modelled by SF dependency and Hammock. 

In this case duration of Activity B needs to be automatically adjusted back (not forward) to accommodate an earlier finish to of Activity A. If the finish of Activity B doesn’t depend on another task, it will be a normal activity. If the finish depends on another task, it should have a hammock type. A hammock activity must have at least one FS or SS predecessor, so it can’t have SF predessesor with Activity A.

The FS dependency on Hammock guarantees that the start of Activity B and the finish of Activity A have an overlap.

It is worth mentioning that to have a real overlap, of may be necessary to add a small lag or lead between activities in both scenarios.

Summary

It is essential to understand which activity is a driver and which is driven. It may not be evident with the simulation of overap activities. 

Modelling an overlap scenario may require using Start-to-Finish dependency with a Hammock activity. 

 

Alex Lyaschenko

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

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