Artificial Project Periods

Project delivery is a continuous process.
Like an assembly line, work flows seamlessly: an 8:00 AM start follows a 5:00 PM finish the previous day, and Monday naturally continues where Friday ended.
However, not every activity can be interrupted.
You can’t start boiling water at 4:55 PM, stop at 5:00 PM, and expect to make tea at 8:00 AM the next morning. Some processes must start and finish within the same uninterrupted working period.
This leads to two important rules.

If a process cannot be interrupted, this constraint must be explicitly programmed in the project delivery model:

• Some tasks require “immediately” after logic allowing a successor start no later than defined period (or without any delay).
• Other activities should not be scheduled to start unless there is sufficient time for it to finish within the available working period.

Traditional CPM dependency types (FS, SS, FF and SF) cannot model this behaviour. They require additional project data modelling capabilities.
If these technological constraints exist but are not represented correctly, then both what-if analysis and Monte Carlo Simulation will produce unreliable results because the underlying delivery model does not reflect reality.

Artificial working periods make projects slower.
Although organising work into predefined blocks usually simplify planning and control, it often introduces hidden delays between predecessor and successor activities. These delays may not immediately affect the delivery date, but they accumulate and consume valuable project float. When uncertainty inevitably occurs, that lost float is no longer available to absorb disruptions.
Common examples include:

• Critical features planned to start at the next Agile sprint instead of commencing them immediately after enabling features are ready;
• a four-hour task being allocated an entire working day simply because it is easier to plan;
• features developed during an Agile sprint waiting for the next production release;
• fixed review and approval periods that delay work for administrative rather than technical reasons.
  These are not technological constraints. They are programmed delays.

Effective project delivery requires project processes to be planned around real-world constraints. This is the foundation of the Resource Critical Path Method (RCPM), which focuses on accurate project data modelling. Rather than simplifying reality through unrealistic assumptions, RCPM enables project teams to model and manage complexity, resulting in more reliable planning, forecasting, and decision-making.

The Resource Critical Path Method (RCPM) addresses both challenges.

An RCPM delivery model represents project processes as it is can be executed. It introduces uninterrupted (“no-break”) periods only where they are genuinely required by technology or the nature of the work, while eliminating artificial time blocks that add no value.

The result is an optimised delivery model that more accurately reflects reality, preserves valuable project float, improves the reliability of scenario analysis and Monte Carlo Simulation, and ultimately enables faster and more predictable project delivery.