TECHNICAL SPECIFICATION OF RDCPM STANDARD
 

Historical Setting

The Critical Path Method (CPM) of planning and scheduling, and related methodologies was developed in the mid to late 1950s.  The earliest methodologies fell into two main camps.  The first was initially called the Kelley-Walker Method, then the Critical Path Method (CPM) and yet later the Activity-On-Arrow Method (AOA) to distinguish from newer variants, and yet later still the Arrow Diagramming Method (ADM) or variant of CPM as a more easily remembered acronym.  The second was Program Evaluation Review Technique (PERT.)  In the late 1950s and early to mid 1960s a new variant of CPM was developed which was initially named the Arrow-On-Node Method (AON) and later renamed the Precedence Diagramming Method (PDM) or variant of CPM.  A number of variants and extensions of the traditional or ADM variant of CPM and a somewhat larger number of variants or extensions of the PDM variant of CPM have been introduced over the years as well as several variations or extensions of the PERT methodology.  These variations or extensions have the effect of allowing the same data input to the CPM or PERT methodology to have differing output or outcomes calculated by such slightly differing methodologies. 

The Relationship Diagramming Method (RDM) or variant of CPM was developed in 2005 by Fredric L. Plotnick of the Commonwealth of Pennsylvania of the United States of America.  In an effort to prevent a similar balkanization of variants of RDM, Mr. Plotnick has created a standard that will hopefully be embraced by all who desire to implement the RDM variant of CPM.  While use of the standard is available to all, claims to be compliant with the standard and use of the RDCPM Certified Mark are restricted to those who have been given such permission by the holder of the Certification Mark. 

Technical Standard  Required Data Fields for Technical Standard  Commentary Upon Required Data Fields

1.        The RDCPM Standard requires that the Relationship Diagramming Method (hereinafter “RDM”) variant of CPM include logic networks composed of three elements, namely events, activities restraints (hereinafter “activities”) and logic restraints (hereinafter “restraints.”) 

2.        Events are elements of the logic network that have a null duration and represent a point in time. 
§  Events shall be capable of being addressed by a unique identification number (or string of alpha-numeric characters.) 
§  Events shall be capable of being assigned a description of between 24 and 64 characters. 
§  Events shall be capable of being assigned user designated code fields including fields formatted for alpha-numeric, numeric and Boolean logic (True/False) data. 

2.1.   An Event may occur independent of an Activity, or at the start of an Activity, or at the finish of an Activity or within an Activity.
§  An Event may be independent, to be known as an “e-Event,” and not considered part of an Activity. 
 §  An e-Event may only be immediately followed by a logic restraint and may not be immediately followed by an Activity. 
    §  An e-Event may only be immediately preceded by a logic restraint and may not be immediately preceded by an Activity. 
 §  An e-Event may be immediately preceded by a “FS,” “SS,” “PS” or “RS” Restraint and may not be immediately preceded by a "FR" or "FP" Restraint.
 §  An e-Event may be immediately succeeded by a “FS,” “FF,” ““FR” or “FP” Restraint and may not be immediately succeeded by a "PS" or "RS" Restraint.
§  An Event shall be assigned to the start of each Activity and shall be designated as the “i-Event" of such Activity.
§  An i-Event is a part of and must be followed by an Activity; an i-Event may not be preceded by an Activity.
§  An i-Event may be followed by zero, one or more "SS," "SF," "SR" or "SP" Restraints; an i-Event may be preceded by one or more "FS," "SS," "PS" or "RS" Restraints.
§  An Event shall be assigned to the finish of each Activity and shall be designated as the “j-Event" of such Activity. 
§  A j-Event is a part of and must be preceded by an Activity; a j-Event may not be succeeded by an Activity.
§  A j-Event may be preceded by zero, one or more "FF," "SF," "PF" or "RF" Restraints; a j-Event may be succeeded by one or more "FS," "FF," "FP" or "FR" Restraints. 
§  An Event shall be assigned to be within each Activity where partial performance of such Activity is a predecessor or successor of a Restraint leading to or from another Event or Activity, and shall be designated as a “k-Event" of such Activity. 
§  A k-Event is a part of an Activity and must be both preceded an d succeeded by some portion of the duration of the activity.
§  A k-Event may neither be preceded nor succeeded by an Activity.
§  A k-Event may be preceded by zero, one or more "SR," "SP," "FP" or "FR" Restraints; a k-Event may be succeeded by zero, one or more "PS," "RS," "PF" or "RF" Restraints.

2.2.   Mandatory Code Fields required available for data entry:  Events shall be capable of being assigned by the user a date or time of Actual Occurred (“AO.”)

2.3.   Mandatory Code Fields to be calculated:  Events shall be capable of being assigned by calculation a time or date of Early Occurred (“EO,”) Late Occurred (“LO”) and Junior Late Occurred (“JLO.”)  Events shall be capable of being assigned by calculation a duration of Total Float (“TF”) and Junior Total Float (“JTF.”)

2.4.   A logic network may have one or more Events that do not have a predecessor; however, these shall be highlighted as being “open ends.”  A logic network may have one or more Events that do not have a successor; however, these shall be highlighted as being “open ends.” 

3.        Activities are elements of the logic network that have a positive duration and represent a definable scope of work having a definable duration and progressing from a preceding Event to a succeeding Event. 
§   Activities shall be capable of being addressed by a unique identification number (or string of alpha-numeric characters.) 
§  Activities shall be capable of being assigned a description of between 24 and 64 characters. 
§  Activities shall be capable of being assigned user designated code fields including fields formatted for alpha-numeric, numeric and Boolean logic (True/False) data. 

3.1.   An Activity shall start at an i-Event and end at a j-Event, and progress from the i-Event to the j-Event. 

3.1.1.           Every Activity shall be preceded by an Event, to be known as an “i-Event,” and considered part of that Activity.  An i-Event may be immediately followed by either an Activity or by a “SS,” “SF,” “SR” or “SP” Restraint.  An i-Event may be immediately preceded by “FS,” “SS,” “PS” or “RS” Restraint and may not be immediately preceded by an Activity. 

3.1.2.           Every Activity shall be succeeded by an Event, to be known as a “j-Event,” and considered part of that Activity.  A j-Event may be immediately followed by a “FS,” “FF,” “FR” or “FP” Restraint and may not be immediately followed by an Activity.  A j-Event may be immediately preceded by a “FF,” “SF,” “PF” or “RF” Restraint and may not be immediately preceded by another Activity. 

3.2.   An Activity shall be capable of being subdivided into two or more smaller activities of a more detailed definition and each having a duration from from a preceding Event to a succeeding Event. 

3.2.1.           An Activity may be split by one or more Events, each to known as a “k-Event,” and considered part of that Activity.  A k-Event may be immediately followed by a “PS,” “RS,” “PF” or “RF” Restraint and may not be immediately followed by another Activity.  A k-Event may be immediately preceded by a “FR,” “FP,” “SR” or “SP” Restraint and may not be immediately preceded by another Activity.

 3.3.   Mandatory Code Fields required available for data entry:  Activities shall be capable of being assigned by the user an Original Duration (“OD,”) Remaining Duration (“RD,”) Percent Complete of Duration (“PCT,”) Fraction Complete of Duration (“##/##”,) a time or date of Actual Start (“AS”) and a time or date of Actual Finish (“AF.”)  Activities shall be capable of being assigned by the user a Specified Actual Duration (“sAD”) that will override the calculated Actual Duration (“AD.”)

3.4.   Mandatory Code Fields to be calculated:  Activities shall be capable of being assigned by calculation a time or date of Early Start (“ES,”) Early Finish (“EF,”) Late Start (“LS,”) Late Finish (“LF,”) Junior Late Start (“JLS”) and Junior Late Finish (“JLF.”)  Activities shall be capable of being assigned by calculation an Actual Duration (“AD”) based upon the calendar of the subject Activity and a Calendar Independent Actual Duration (“cAD”) based upon a calendar not having non-work periods of time.  Activities shall be capable of being assigned by calculation a duration of Total Float (“TF,”) Junior Total Float (“JTF,”) Free Float (“FF”) and Independent Float (“IF.”) 

 3.5.   Durations of Activities are units of time during which work is to be performed. 
§  A Duration of zero shall be defined as being less than one-half of the smallest recorded or recordable unit of time in the logic network. 
§  An Original Duration (“OD”) is an estimate of the period of time of active work required to perform the specified scope of work prior to the start of work on the Activity. 
§  A Remaining Duration (“RD”) is an estimate of the period of time of active work required to complete performance of the specified scope of work after the start of work on the Activity. 
§  An Actual Duration (“AD”) is a measurement of the period of time of active work required to perform the specified scope of work or portion thereof complete at the time of such measurement. 

3.5.1.           An Original Duration (“OD”) shall be capable of being user designated or calculated from user designated resource requirements, availability and productivity data. 

3.5.2.           A Remaining Duration (“RD”) shall be capable of being user designated or calculated from a user designated percent complete (“PCT”) or fractional complete (“##/##,”) or may be designated to be calculated based upon the passage of time from a user designated actual start date.

3.5.3.           An Actual Duration (“AD”) shall be capable of being calculated from user designated start and finish times (or dates) or being user designated to adjust for days not worked between the user designated start and finish times. 

 3.6.   Mandatory Code Fields required for calculation:  An Activity shall be capable of being coded to indicate how the duration of the Activity will be defined and used in calculations as herein provided: 

3.6.1.           Durations shall be capable of being recorded or calculated based upon a calendar individual to an Activity, a calendar individual to one resource, calendars individual to two or more resources or to a calendar of the common times or dates of availability of two or more resources.  

3.6.2.           Durations of Activities shall be capable of being user designated as being interruptible or continuous.  

3.6.3.           Remaining Durations of Activities shall be capable of being user designated as being based upon measured progress or upon the passage of time from a user designated actual start time (or date). 

3.6.4.           Remaining Durations of Activities based upon measured progress that have been Started-Out-Of-Sequence shall be capable of being user designated as being measured from:

3.6.4.1.      the calculated early start based upon the network logic, even if such should cause a continuous activity duration to be interrupted (this recognized as being the Retained Logic method,)

3.6.4.2.      the data date, ignoring the network logic for all subsequent calculations (this recognized as the Legacy Progress Override method,)

3.6.4.3.      the data date, retaining the network logic to calculate the early finish of the activity as the later of the data date plus duration or the calculated early start based upon the network logic plus duration (this recognized as the Modified Progress Override method.) 

3.6.5.           Remaining Durations of Activities based upon passage of time from a user designated actual start time that have been Started-Out-Of-Sequence shall be capable of being user designated as being measured from:

3.6.5.1.      the calculated early start based upon the network logic, even if such should cause a continuous activity duration to be interrupted (this recognized as being the Retained Logic method,)

3.6.5.2.      the recorded actual start time (or date,) ignoring the network logic for all subsequent calculations (this recognized as the Legacy Progress Override method,)

3.6.5.3.      the recorded actual start time (or date,) retaining the network logic to calculate the early finish of the activity as the later of the data date plus duration or the calculated early start based upon the network logic plus duration (this recognized as the Modified Progress Override method.) 

4.        Restraints are elements of the logic network that may have a null duration or positive duration and represent a relationship from one Event to another Event. 
§  A Restraint may represent a definable scope of work from one Event to another Event; however, the passage of time and not progress is measured for a Restraint. 
§  Restraints may not be subdivided. 
§  Restraints shall not be capable of being addressed by a unique identification number (or string of alpha-numeric characters,) but rather shall be addressed by pairing of the unique identification number of the preceding and succeeding activities or events. 
§  Restraints shall be capable of being assigned a description of between 24 and 64 characters. 
§  Restraints shall be capable of being assigned user designated code fields including fields formatted for alpha-numeric, numeric, data and Boolean logic data. 

 4.1.   Mandatory Code Fields required for calculation:  Restraints shall be capable of being assigned by the user an Lag Original Duration (“LOD,”) Lag Remaining Duration (“LRD,”) Percent Complete of Lag Duration (“LPCT,”) Fraction Complete of Duration (“##/##”,) a time or date of Actual Start (“LAS”) and a time or date of Actual Finish (“LAF.”)  Restraints shall be capable of being assigned by the user a Specified Actual Duration (“LCD”) that will override the calculated Actual Duration (“LAD.”)

4.2.   Mandatory Code Fields to be calculated:  Restraints shall be capable of being assigned by calculation a time or date of Early Start (“LES,”) Early Finish (“LEF,”) Late Start (“LLS,”) Late Finish (“LLF,”) Junior Late Start (“LJLS”) and Junior Late Finish (“LJLF.”)  Restraints shall be capable of being assigned by calculation an Actual Duration (“LAD”) based upon the calendar of the subject Restraint and a Calendar Independent Actual Duration (“cLAD”) based upon a calendar not having non-work periods of time.  Restraints shall be capable of being assigned by calculation a duration of Total Float (“TF,”) Junior Total Float (“JTF,”) Free Float (“FF”) and Independent Float (“IF.”) 

4.3.   Durations of Restraints are units of time:

4.3.1.           that must pass between the occurrence of the Event at the start of the Restraint until the Event at the finish of the Restraint, to be designated as a Passage-type Restraint, or

4.3.2.           during which work of the Activity referenced by the restraint is to be performed , to be designated as a Performance-type Restraint.

4.4.   For a Passage-type Restraint, a Lag Original Duration (“LOD”) is an estimate of the period of time that must pass between the occurrence of the Event at the start of the Restraint until the Event at the finish of the Restraint. 
§  A Lag Remaining Duration (“LRD”) is a calculated period of time of the period of time that must pass between the recorded actual occurrence of the Event at the start of the Restraint until the Event at the finish of the Restraint. 
§  A Lag Actual Duration (“LAD”) is the calculated period of time between the recorded actual occurrence of the Event at the start of the Restraint until the earlier of the recorded actual occurrence of the Event at the finish of the Restraint or the data date. 
§  A Lag Cost Duration (“LCD”) is a measurement of the period of time of active work performed (if any) during the passage of time of the Restraint.  . 

4.5.   For a Progress-type Restraint, a Lag Original Duration (“LOD”) is (1) an estimate of a portion of the duration of the Activity preceding the Restraint that must be completed prior to the occurrence of the Event succeeding the Restraint, or (2) an estimate of a portion of the duration of the Activity succeeding the Restraint that cannot start (or continue) until the occurrence of the Event preceding the Restraint. 
§  A Lag Remaining Duration (“LRD”) is a calculated period of time based upon the recorded progress of the Activity referenced by the Restraint. 
§  A Lag Actual Duration (“LAD”) is the calculated period of time between the recorded actual occurrence of the Event at the start of the Restraint until the earlier of the recorded actual occurrence of the Event at the finish of the Restraint or the data date. 
§  A Lag Cost Duration (“LCD”) is a measurement of the period of time of active work performed (if any) during the passage of time of the Restraint.  . 

 4.6.   Mandatory Code Fields required for logic verification and calculation:  A Restraint shall be capable of being coded to indicate the reason why it is included in the logic network by two code fields to be named the “Reason” code and the “Why” code.  The reason why the restraint is included in the logic network may also be more fully described in the Restraint description as provided above. 

4.6.1.           The “Reason” code for Restraints shall be user designated as being either a “P,” “J” or “R” restraint.  Restraints may also be designated as a “L” restraint as a result of the calculation algorithm. 

4.6.1.1.      The “P” restraint represents a physical dependency between Events or Activities. 
§  “Why” codes for “P” restraints may be defined by the user. 
§  Examples include “gravity” and “contract requirement.” 
§  The immutability of the “P” restraint may also be defined by the “Why” code. 
§  Examples include “[subject to relaxation by] falsework” and “[subject to reduced duration by] concrete additives.” 

4.6.1.2.      The “J” restraint represents a physical dependency between Events or Activities where it is desired that the immediate predecessor (and predecessors thereof) be finished in time so as not to delay the early occurrence or start of the successor Event or Activity. 
§  The “J” restraint and it’s “Why” code are otherwise the same as the “P” restraint.

4.6.1.3.      The “R” restraint represents a resource dependency between Events or Activities where the successor could otherwise occur or start earlier if additional resources were available. 
§  “Why” codes for “R” restraints may be defined by the user. 
§  Examples include “labor,” “[a specific] crew,” “[a specific] craft,” “a specific] person,” “equipment,” “materials,” “access,” “funding” and others. 

4.6.1.4.      The “L” restraint represents a resource dependency between Events and Activities that has been added by application of a leveling algorithm or routine. 
§  The “L” restraint and it’s “Why” code are otherwise the same as the “R” restraint; however, the “Why” code will be based upon the resource(s) being leveled upon.

 4.7.   Mandatory Code Fields required for defining the logic between Events and Activities and calculation:  A Restraint shall be capable of being coded to indicate the appropriate Event at the start, finish or within an Activity, or independent Event, from which and to which the restraint connects, and to indicate the appropriate lag duration, if any, between these events. 

4.7.1.           The “FS” restraint represents the predecessor Event must occur before the successor Event may occur. 
§  The “FS” restraint is only supported leaving from an e-node or j-node type Event and going to an e-node or i-node type Event. 
§  The “FS” restraint is a passage type restraint. 
§  The duration of a “FS” restraint is independent of the preceding or succeeding Activity. 

4.7.2.           The “SS” restraint represents the predecessor Event must occur before the successor Event may occur. 
§  The “SS” restraint is only supported leaving from an i-node type Event and going to an i-node type Event. 
§  The “SS” restraint is a passage type restraint. 
§  The duration of a “SS” restraint is independent of the preceding or succeeding Activity.

4.7.3.           The “PS” restraint represents the predecessor Event must occur before the successor Event may occur. 
§  The “PS” restraint is only supported leaving from a k-node type Event and going to an e-node or i-node type Event. 
§  The “PS” restraint is a progress type restraint. 
§  The duration of a “PS” restraint is based upon the preceding Activity and represents that portion that must be complete before the start of the successor Activity. 
§  The duration of the “PS” restraint is independent of the succeeding Activity.

4.7.4.           The “RS” restraint represents the predecessor Event must occur before the successor Event may occur. 
§  The “RS” restraint is only supported leaving from a k-node type Event and going to an e-node or i-node type Event. 
§  The “RS” restraint is a progress type restraint. 
§  The duration of a “RS” restraint is based upon the preceding Activity and represents that remaining portion to which the Activity must be complete before the start of the successor Activity. 
§  The duration of the “RS” restraint is independent of the succeeding Activity.

4.7.5.           The “FF” restraint represents the predecessor Event must occur before the successor Event may occur. 
§  The “FF” restraint is only supported leaving from a j-node type Event and going to a j-node type Event. 
§  The “FF” restraint is a passage type restraint. 
§  The duration of the “PS” restraint is independent of the preceding or succeeding Activity.

4.7.6.           The “FR” restraint represents the predecessor Event must occur before the successor Event may occur. 
§  The “FR” restraint is only supported leaving from a j-node type Event and going to a k-node type Event. 
§  The “FR” restraint is a progress type restraint. 
§  The duration of a “FR” restraint is based upon the succeeding Activity and represents that portion that may continue only after completion of the predecessor Activity. 
§  The duration of the “FR” restraint is independent of the preceding Activity.

4.7.7.           The “FP” restraint represents the predecessor Event must occur before the successor Event may occur. 
§  The “FP” restraint is only supported leaving from a j-node type Event and going to a k-node type Event. 
§  The “FP” restraint is a progress type restraint. 
§  The duration of a “FP” restraint is based upon the succeeding Activity and represents that portion that may be complete before the completion of the predecessor Activity. 
§  The duration of the “FR” restraint is independent of the preceding Activity.

4.7.8.           The “SF” restraint represents the predecessor Event must occur before the successor Event may occur. 
§  The “SF” restraint is only supported leaving from an i-node type Event and going to a j-node type Event. 
§  The “SF” restraint is a passage type restraint. 
§  The duration of a “SF” restraint is independent of the preceding or succeeding Activity.

4.7.9.           The “SP” restraint represents the predecessor Event must occur before the successor Event may occur. 
§  The “SP” restraint is only supported leaving from an i-node type Event and going to a k-node type Event. 
§  The “SP” restraint is a progress type restraint. 
§  The duration of a “SP” restraint is based upon the succeeding Activity and represents that portion that may be complete before the start of the predecessor Activity. 
§  The duration of the “SP” restraint is independent of the preceding Activity.

4.7.10.        The “SR” restraint represents the predecessor Event must occur before the successor Event may occur. 
§  The “SR” restraint is only supported leaving from an i-node type Event and going to a k-node type Event.
§   The “SR” restraint is a progress type restraint. 
§  The duration of a “SR” restraint is based upon the succeeding Activity and represents that portion that may continue only after the start of the predecessor Activity. 
§  The duration of the “SR” restraint is independent of the preceding Activity.

4.7.11.        The “PF” restraint represents the predecessor Event must occur before the successor Event may occur. 
§  The “PF” restraint is only supported leaving from a k-node type Event and going to an e-node or j-node type Event. 
§  The “PF” restraint is a progress type restraint. 
§  The duration of a “PF” restraint is based upon the preceding Activity and represents that portion that must be complete before the completion of the successor Activity. 
§  The duration of the “PF” restraint is independent of the succeeding Activity.

4.7.12.        The “RF” restraint represents the predecessor Event must occur before the successor Event may occur. 
§  The “RF” restraint is only supported leaving from a k-node type Event and going to an e-node or j-node type Event. 
§  The “RF” restraint is a progress type restraint. 
§  The duration of a “RF” restraint is based upon the preceding Activity and represents that remaining portion to which the Activity must be complete before the completion of the successor Activity. 
§  The duration of the “RF” restraint is independent of the succeeding Activity.

4.7.13.        The “CT” restraint represents that the predecessor Event and successor Event are in fact the same Event, and that the preceding Activity and succeeding Activity are to be performed contiguously and continuously, subject to the calendars of the Activities. 
§  The “CT” restraint is only supported leaving from a j-node type Event and going to an i-node type Event. 
§  The start of preceding Activity is calculated as equal to the start of the succeeding Activity (as may be calculated by other preceding restraints or constraints) less the lag duration of the CT restraint and less the duration of the preceding Activity. 
§  The duration of the “CT” restraint is independent of the preceding or succeeding Activity.

4.7.14.        The “CC” restraint represents the Activity following the successor Event is to be performed concurrently with and not independently of the Activity following the predecessor Event. 
§  The “CT” restraint is only supported leaving from an i-node type Event and going to an i-node type Event. 
§  The “CC” restraint is a progress type restraint. 
§  The duration of the Activity following the preceding Event shall be recalculated if required to be not less than the lag duration of the restraint plus the duration of the Activity following the succeeding Event. 
§  The duration of a “CC” restraint is based upon the preceding Activity and represents that portion that must be complete before the start of the successor Activity. 
§  The duration of the “CC” restraint is independent of the succeeding Activity.

4.7.15.        The “DS” restraint represents a combination of the “SS” and “FF” restraints, each having the same lag duration. 
§  The “DS” restraint is only supported leaving from an i-node type Event and going to an i-node type Event. 
§  The “DS” restraint is only supported where the duration of the Activity following the preceding Event and duration of the Activity following the succeeding Event are equal. 
§  The “DS” restraint is a passage type restraint. 
§  The duration of a “DS” restraint is independent of the preceding or succeeding Activity.

4.7.16.        The “DP” restraint represents a combination of the “PS” and “RF” restraints, each having the same lag duration. 
§  The “DP” restraint is only supported leaving from a k-node type Event and going to an i-node type Event. 
§  The “DP” restraint is only supported where the duration of the Activity following the preceding Event and duration of the Activity following the succeeding Event are equal. 
§  The “DP” restraint is a progress type restraint. 
§  The duration of a “DS” restraint is based upon the preceding Activity and represents that portion that must be complete before the start of the successor Activity. 
§  The duration of the “DS” restraint is independent of the succeeding Activity. 

4.7.17.        The “DR” restraint represents a combination of the “RS” and “PF” restraints, each having the same lag duration. 
§  The “DR” restraint is only supported leaving from a k-node type Event and going to an i-node type Event. 
§  The “DR” restraint is only supported where the duration of the Activity following the preceding Event and duration of the Activity following the succeeding Event are equal. 
§  The “DP” restraint is a progress type restraint. 
§  The duration of a “DR” restraint is based upon the preceding Activity and represents that remaining portion to which the Activity must be complete before the start of the successor Activity. 
§  The duration of the “DR” restraint is independent of the succeeding Activity. 

4.7.18.        PR, PP, RR and RP restraint types shall be recognized as valid but that shall not be supported by the Standard as each requires two lags (performance of predecessor and successor) but instead may be implemented by a PS (or RS) restraint from a predecessor Activity to an e-node Event and then from that Event a FR (or FP) restraint to the successor Activity.
 

4.8.   Mandatory Code Fields required for calculation:  A Restraint shall be capable of being assigned, by calculation, a Relationship Code to indicate how user defined code fields differ from the Events and Activities preceding and succeeding the Restraint. 

4.8.1.           For comparison of user defined code fields that are alphanumeric, and logical (“T/F”) the choices shall be null (or empty,) equal (“=”) or not equal (“≠.”) 

4.8.2.           For comparison of user defined code fields that are numeric, dates or resource units, the choices shall be null, equal (“=,”) not equal (“≠,”) less than (“<”) or more than (“>.”)

4.9.   Mandatory Code Fields required for calculation:  A Restraint shall be capable of being coded to indicate how the duration of the Restraint will be defined and used in calculations as herein provided: 

4.9.1.           For a Passage-type Restraint:

4.9.1.1.      Durations shall be capable of being recorded or calculated based upon a calendar individual to a Restraint, or to the calendar of the predecessor or successor Activity or Event to the Restraint. 

4.9.1.2.      Remaining Durations of Activities that have been Started-Out-Of-Sequence shall be capable of being user designated as being measured from:

4.9.1.2.1.  the calculated early start based upon the network logic, even if such should cause a restraint duration to be interrupted (this recognized as being the Retained Logic method,)

4.9.1.2.2.  the recorded actual start time (or date,) ignoring the network logic for all subsequent calculations (this recognized as the Legacy Progress Override method,)

4.9.1.2.3.  the recorded actual start time (or date,) retaining the network logic to calculate the early finish of the Restraint as the later of the data date plus duration or the calculated early start based upon the network logic plus duration (this recognized as the Modified Progress Override method.) 

4.9.2.           For a Progress-type Restraint:

4.9.2.1.      Durations shall be recorded or calculated based upon the calendar or the Activity referenced by the Restraint. 

4.9.2.2.      Remaining Durations of Activities that have been Started-Out-Of-Sequence shall be measured based upon the Started-Out-Of-Sequence option chosen for the Activity referenced by the Restraint. 

 5.        Notation:  The approved notation must provide the ability to depict:
·       events, including:
     ·       a unique event ID tag,
     ·       a description,
     ·       a calendar and
     ·       user defined event codes,
·       logic restraints, including:
     ·       a description,
     ·       a reason/why code,
     ·       a lead/lag code,
     ·       an out-of-sequence duration code,
     ·       probabilistic durations (O, M, P) with associated calendar and
     ·       user defined relationship codes and
·       activities, including:
     ·       a unique activity ID tags,
     ·       a description,
     ·       a progress/passage duration code,
     ·       an interruptible/continuous duration code,
     ·       a out-of-sequence duration code,
     ·       probabilistic durations (O, M, P) with associated calendar,
     ·       user defined activity codes,
     ·       resource codes and quantities and
     ·       cost codes and values

Example of Approved Notation: