To create a GPM schedule, users draw and place objects – such as activities, milestones, and benchmarks – on a time-scaled canvas. Objects are linked together to establish logical, precedence relationships. These relationships are governed by the Logic Diagramming Method, a blend of the Arrow Diagramming Method and the Precedence Diagramming Method. In total, LDM permits 12 relationship types to account for all possible dependencies between objects. The resulting web of logically related, dated objects and their relationships forms a network diagram. Object relationships form the backbone of a GPM network. They are used to calculate a number of object attributes, including [|link gap and object buffer, drift, and float]. As objects and their relationships are added to or modified in the schedule, GPM continuously re-calculates and updates gap for all links and float for all dated objects. Link gaps are calculated from the dates of two related activities and floats are algorithmically calculated from gaps.
Differences between GPM and CPM
The Critical Path Method is the traditional mathematical algorithm used for schedule logic computation. GPM utilizes a different algorithm than CPM and thus produces its own distinct schedule attributes.
Planned dates vs. early dates
In a GPM network, objects not residing on the critical path, and thus having float, are permitted to be scheduled anywhere within their float range and are not forced to their early or late dates. This action in a GPM network is referred to as scheduling objects on planned dates. This is contrary to CPM logic, where a forward and backward pass algorithm defaults objects to their early dates, unless additional logic is introduced to constrain an object to a later date. GPM logic permits the as-planned scheduling framework because logic links retain their own attributes, namely gap.
Schedule Attributes
Gap
GPM allows users to place an object anywhere in between its early and late dates; consequently, link gap emerges between objects. Link gap permits object scheduling on planned dates while retaining the Total Float value of the network. The link gap values become the basis for calculating floats in a GPM network. The as-planned framework introduces additional schedule values of buffer, drift, and float.
Buffer
CPM calculates available slippage in Free Float and Total Float. CPM measures Free Float by how much a predecessor activity may be delayed without causing a delay to its nearest successor activity. In GPM this is called buffer and it is calculated as the minimum of the link gaps for all logic ties to successor objects.
Drift
Because activities in a CPM network default to their early dates, CPM does not calculate activity movement in the opposite direction – namely, how much an activity may backslide or extend to earlier dates without affecting predecessor activities. GPM permits activity placement between early and late dates and thus introduces this value of “preceding float” as drift. GPM calculates drift as the minimum of the link gaps for all logic ties to predecessor objects.
Float
CPM Total Float is measured by how much an activity may be delayed without delaying the project completion date. In GPM this is called float, with the distinction that it is measured with respect to planned dates rather than early dates. Thus, the GPM value of float plus drift is analogous to Total Float in CPM.
Real-time vs. sequential compiling
CPM relies on activity dates as the basis for float calculations, where total float is determined by the difference between late finish dates and early finish dates. This requires a standby calculation engine to perform a forward pass and a backward pass of the entire network when planning ceases or when an interim calculation is necessary for further planning. The result is that planning and scheduling are separate processes performed in sequential order. In GPM’s time-scaled framework, dates are innate, real-time attributes of network objects. This permits GPM to use the link gap between two objects for the float calculation and thus schedule data and object attributes are continuously updated in real-time, as changes to the schedule are committed. This allows for dynamic feedback from the schedule; users are permitted to execute schedule optimization, time and cost trade-offs, resource management and other analysis concurrently as the schedule is being built.
