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. 

 

COMMENTS UPON TECHNICAL SPECIFICATION FOR COMPLIANCE WITH STANDARD 

Activity Data Items 1 – 5:  These activity ID fields should be of specified length if data is to be transportable between software products without adjustment.  Note that the Event ID’s are analogous to, but not the same as, the ADM i-j format.  While each activity progresses from an i-event to a j-event, such events are unique to one activity only and may only be connected to other activities (or events) via a restraint.  See Restraint Data Item ## below.

 

Activity Data Items 6 – 9:  These activity description fields may be proprietary by software vendor as to length of data field.  The inclusion of logs and memo fields to expand the description are recommended.  A field for activity codes is required as the use of such coding is tied to intelligent assignment of outlier (optimistic and pessimistic) durations, as well as for trend analysis purposes. 

 

Activity Data Item 10:  Activity Duration Calendar specifies association or correlation between calculated day numbers and dates or other time units, as well as further defining duration.

 

Activity Data Item 11:  Types of activities shall include:

 

 

Specified Duration

Keyed duration will override sum of split activity durations – delta allocated amongst

 

Summed Duration

Keyed duration will be overridden by sum of split activity durations

 

Split Activity

Detail of a previously entered  activity in a linearly sequenced order (durations total)

 

Included Task of Activity

Detail of a previously entered  activity not in sequenced order (durations do not total)

 

Logic Hammock

from j-event to i-event via FS logic with software check for existence of logic

 

NoLogic Hammock

from j-event to i-event via FS logic without software check for existence of logic

 

PDM Hammock

from i-event from j-event via SS to FF logic

 

Code Summary

A non-logic activity from the start to finish of a group of activities of same act code

 

WBS Summary

A non-logic activity from the start to finish of a group of activities of same WBS code

 

Resource Driven Indep

Keyed dur will be overridden by driving resources independently (any one available)

 

Resource Driven Meeting

Keyed dur will be overridden by driving resources together (only as all are available)

 

 

 

 

 

 

 

 

 

 

Activity Data Items 12 – 17:  Keyed original durations are retained even if such are overridden by the software algorithm.  Such overriding may be activity detail (Split,) calculation of hammock durations, resource driven durations, constraints (expected finish, etc.) and possibly other causes.  Note that outliers may be entered explicitly or may entered at +/- a percent of the most likely value. 

 

Activity Data Items 18 – 20:  Duration codes include:

 

 

DurCode P/C/K

 

 

Progressed

Progress is calculated by OD – RD (= Original Duration – Remaining Duration)

 

Clocked

Progress is calculated by DD – AS (= DataDate – Actual Start)

 

Clock-but-checK

Progress is calculated by DD – AS ≥ 1, reduction from 1 requires RD = OD

 

 

This code sets whether the remaining duration should be manually reduced by observation, or may be automatically reduced after an Actual Start is entered, on an individual activity basis.  The third choice, clockchecK, reduces to one day then remains at one day remaining duration until manually reduced to zero (or an Actual Finish is entered.)

 

 

 

 

DurCode C/I/S

 

 

Continuous

ES calculated from predecessor only

 

Interruptible

ES is later of that calculated from predecessors, or EF – RD

 

Stretched

ES is later of that calculated from predecessors, or EF – RD but EF – ES ≤ OD + x%

 

 

This code sets the choice of Continuous or Interruptible duration on an individual activity basis.  The third choice (Stretch) allows the duration to be stretched (with an impact to use of resources assigned to the activity.)  While this may in the future be expanded to an activity-by-activity basis, current implementation shall require only one system-wide stretch code.

 

 

 

 

DurCode M/R/P

 

 

Modified Logic

Activities started out-of-sequence may continue, but not be calculated as completed

 

Retained Logic

Activities started out-of-sequence may not continue until all predecessor complete

 

Progress Override

Activities started out-of-sequence may continue without regard to predecessors

 

 

This code sets the choice of Retained Logic, Progress Override or the new “middle ground” Modified Logic™, to an activity-by-activity basis. 

 

 

 

 

Activity Data Items 21 – 22:  Keyed remaining durations are retained even if such are overridden by the software algorithm.  Note that remaining durations may be entered explicitly or may be entered as a percent complete or fractional units complete.  This code field allows entry of remaining duration during an update, in the user’s “lingo.”  Thus, the user may say, update duration is:

·         “3” or “3R” for 3 time units remaining, or

·         “7C” for 7 time units have been complete, or

·         “70%” for 70% (time or units of work) complete, or

·         “14000/20000” for 14,000 of 20,000 units or work complete.  Note maximum units is 99,999.

 

Activity Data Items 23 – 30:  Calculated total number of predecessors to and successors from the beginning, end or middle of an activity; Subset of calculated number of predecessors to the beginning, middle and end of an activity and successors from the beginning, middle and end of an activity. 

 

[An additional six fields may also record the number of “exclusive” predecessors and successors (being such that are the ONLY predecessor from a predecessor activity or ONLY successor to a successor activity) but are not required for this implementation .  These addition of the extra six fields may be very useful in building a more powerful leveling routine.]

 

Activity Data Item 31:  Calculated number of events within (not at beginning or end of) an activity.  Note that two or more restraints may emanate from or terminate to the same event.  (Note issue of restraint-to-k-event-to-restraint needs to be addressed.)

 

Activity Data Items 32– 33:  Actual Start and Actual Finish of activity.  May be keyed or calculated by clock if P/C/K duration code is C or K.

 

Optional Activity Data Items (not in list):  Actual Suspend and Resume Dates for activity performance.  May include one or multiple suspend/resume pairs. 

 

Activity Data Items 34 – 35:  Keyed Actual Duration to override a actual duration calculated from AF – AS or by AF – AS – (RSM – SUS) or by AF – AS – (RSM1 – SUS1) – (RSM2 – SUS2) – (RSMn – SUSn).  Result stored in Actual Duration field.

 

Activity Data Item 36:  Trend Remaining Duration calculated as an adjustment to current RD (if activity started, equal to OD if not started) based upon fraction AD/OD for activities sharing a similar activity code (as specified by user) for which a specified percent of all similar activities has been complete.  For example, when 30% of all activities with user defined activity code “subcontractor” are “electrical” are complete, trend remaining durations will be calculated for remaining 70% of such activities. 

 

Activity Data Items 37 – 40:  Calculated Early Start, Late Start, Early Finish, Late Finish

 

Activity Data Items 41 – 43:  Start Total Float (= LS – ES,) Finish Total Float (= LF – LS,) and Most Critical Total Float (= max STS or FTS.)

 

Activity Data Item 44:  Normalized Most Critical Total Float, calculated upon ordinal day numbers based upon a 24/7/365 calendar without holidays. 

 

Activity Data Item 45 – 46:  Just-in-Time Start and Finish, calculated backward from last instance of a “J” or “Just-in-Time” Logic Restraint Reason code.  The calculation sets the JLFPRED = ESSUCC at the restraint.  Normal rules for the backward pass, e.g., JLFPRED = LSSUCC at restraints having other Reason codes, and JLS = JLF – RD apply.

 

Activity Data Items 47 – 50:  Just-in-Time Start Total Float (= JLS – ES,) Just-in-Time Finish Total Float (= JLF – LS,) Just-in-Time Most Critical Total Float (= max JSTS or JFTS) and Just-in-Time Normalized Most Critical Total Float.

 


 

Event Data Item 1:  This event ID fields should be of specified length if data is to be transportable between software products without adjustment.  Note that the Event ID’s are analogous to, but not the same as, the ADM i-j format.  While each activity progresses from an i-event to a j-event, such events are unique to one activity only and may only be connected to other activities (or events) via a restraint.  See Restraint Data Item ## below.

 

Event Data Items 2 – 5:  These event description fields may be proprietary by software vendor as to length of data field.  The inclusion of logs and memo fields to expand the description are recommended. 

 

Event Data Items 6 – 7:  An Event may act as a GERT gate permitting alternate forms of logic within the logic network.  Where so used, a special Event Type will be used. 

Types of event shall include:

 

 

Normal (Default)

all predecessor restraints required to continue, all successors may then continue

 

GERT nth of many

perform successors when 1st, 2nd, , nth, or last predecessor complete
Data Item 7:  number of predecessors required: 001, 002, …, 999, ‘ALL’

NOTE each predecessor must have multiple successors to avoid OPEN END error

 

GERT .or. (RNG)

perform successor ONE .or. TWO depends upon if random number is below Item 7:

Data Item 7:  random number: 000, 001, 002, …, 999, ‘ALL’

 

GERT LOOP Re-Entry

perform successor ONE again (overwrite ES, EF dates) if successor TWO (which is a type GERT RNG Event) has selected alternate path (TWO)

??

GERT .or. (RNG)

Perform successor ONE, TWO, …, Nth for RNG at one%, two%, …, 100%
[see PertMaster methodology]

 

GERT .or. (condition)

perform successor ONE .or. TWO depending upon if THREE meets condition Item 7:

Data Item 7:  condition:  0,1,2:  “not started,” “started,” “finished”

??

GERT .or. (condition)

perform successor ONE .or. TWO depending upon if THREE meets condition Item 7:

Data Item 7:  condition:  0,1,2,3:  “not started,” “started,” “finished,” “ES<date,” etc.

 

 

 

 

<<< 

Data structure is still in discussion stage for this (these) item(s)

 

Event Data Items 8 – 17:  Calculated number of predecessors and successors to an event; subset of calculated number of predecessors from the beginning, middle and end of an activity (or from another event) and successors to the beginning, middle and end of an activity (or to another event.)

 

Event Data Item 18:  Event Calendar specifies association or correlation between calculated day numbers and dates or other time units. 

 

Event Data Item 19:  Specifies whether dates calculated or reported for this event are set at beginning or end of the day (or other time period, such as shift.) 

 

Event Data Items 20 – 26:  Calculated fields analogous to ES, EF, LS, LF, JLS, JLF, TF, NTF, JTF, NJTF.  These include only one point per event (occurrence) rather than two points (start and finish) associated with activities.  Included are Early Occurrence, Late Occurrence, Just-in-Time Occurrence, Total Float, Normalized Total Float, Just-in-Time Total Float, and Normalized Just-in-Time Total Float. 

 


 

Restraint Data Items 1 – 2:  These Restraint ID fields should be of specified length if data is to be transportable between software products without adjustment.  Note that every restraint begins at an event and ends at an event.  Note that the Event ID’s are analogous to, but not the same as, the ADM i-j format.  While each activity progresses from an i-event to a j-event, such events are unique to one activity only and may only be connected to other activities (or events) via a restraint.  The Restraint I-ID should be the same as the Activity ID of a predecessor activity, with appropriate suffix to equal an Event ID.  The Restraint J-ID should be the same as the Activity ID of a successor activity with appropriate suffix to equal an Event ID. 

 

Thus for a FS restraint from an Activity “1000” and to Activity “1005”, this will be “1000j_____”; for a SS restraint, “1000i _____”; for a FF restraint, “1000j_____”; for a SF restraint, “1000i_____”; for a PS restraint of 5 days, “1000k00005”; for a FP restraint of 5 days, “1005k00005”.   

 

<<<  Data structure is still in discussion stage for this (these) item(s)

 

Restraint Data Items 3 – 4:  These Event ID fields should be of specified length if data is to be transportable between software products without adjustment.  Note that every restraint begins at an event and ends at an event.  Note that the Event ID’s are analogous to, but not the same as, the ADM i-j format.  While each activity progresses from an i-event to a j-event, such events are unique to one activity only and may only be connected to other activities (or events) via a restraint.  The Restraint I-ID should be the same as the Event ID of a predecessor event, or the Event ID within a predecessor activity.  The Restraint J-ID should be the same as the Event ID of a successor event, or the Event ID within a successor activity.  

 

Thus for a FS restraint from an Activity “1000” and to Activity “1005”, this will be “1000j_____”; for a SS restraint, “1000i _____”; for a FF restraint, “1000j_____”; for a SF restraint, “1000i_____”; for a PS restraint of 5 days, “1000k00005”; for a FP restraint of 5 days, “1005k00005”. 

 

 

Restraint Data Item 5:  Reasons for a restraint shall include:

 

P

Physical Restraint

need is physical – successor cannot normally be performed with predecessor

R

Resource Restraint

need is resource limits – resource chosen to flow from predecessor to successor

_

Blank

need is not specified – calculated as though Physical but may be flagged

J

Just-In-Time

need is physical with desire to complete prior to early start of immediate successor

S

Suppressed R

calculated – suppressed as part of a leveling routine for selected resource

L

Leveled R

calculated – added as part of a leveling routine for selected resource

 

Restraint Data Item 6:  The Why for the Reason code field should be of specified length if data is to be transportable between software products without adjustment.  The Why field may be free-form, or preferably will be menu-driven with such menu pre-populated with entries from the resource dictionary, but appendable by the user for additional entries. 

 

Restraint Data Items 7 – 10:  These restraint description fields may be proprietary by software vendor as to length of data field.  The inclusion of logs, memo fields and restraint codes (analogous to activity codes) to expand the description are recommended. 

 

Restraint Data Item 11:  Logic Codes record how events and activities are linked with especial attention to whether the linkage is to the beginning, end or middle of an activity.  Choices include:

 

FS

Finish-to-Start

successor activity (or event) may start (or occur) when predecessor reported complete

lag is measured  from finish of predecessor (Event-at-Finish) by clocked time units

SS

Start-to-Start

successor activity (or event) may start (or occur) when predecessor reported started

lag is measured  from start of predecessor (Event-at-Start) by clocked time units

FF

Finish-to-Finish

successor activity (or event) may finish (occur) when predecessor reported complete

lag is measured  from finish of predecessor (Event-at-Finish) by clocked time units

SF

Start-to-Finish

successor activity (or event) may finish (or occur) when predecessor reported started

lag is measured  from start of predecessor (Event-at-Start) by clocked time units

PS

Partial-to-Start

successor activity (event) may start (occur) when predecessor performance reported

lag is measured  from difference of OD – RD of predecessor (Event-within-Activity)

FP

Finish-to-Partial

successor activity may continue to completion when predecessor reported complete

lag is measured  from difference of OD – RD of successor (Event-within-Activity)

CT

Contiguous FS

predecessor activity (or event) may finish (occur) when successor reported complete

lag is measured  from finish of predecessor (Event-at-Finish) by clocked time units

CC

Concurrent FS

predecessor activity may finish when successor reported complete

successor actv performance automatically progressed with predecessor (override) lag

<<< Data structure is still in discussion stage for this (these) item(s)

DS

Duplicate SS + FF

 

DP

Duplicate PS + FP

 

 

Restraint Data Item 12:  Keyed Logic Duration (Lag) may be a specified number of time units or may be referenced to the reference activity of the restraint, i.e. to the predecessor activity for logic codes FS, SS, FF, SF or PS, to the successor activity for code FP.  Where so referenced, the keyed duration may be expressed as a percentage (e.g. 70%) or fractional value (e.g. 40/72, based upon user defined units of performance) of the reference activity duration.  Thus for logic types FS, SS, FF, SF and PS, the percentage or fraction relates to the original duration of the predecessor; for logic type FP the percentage or fraction relates to the original duration of the successor. 

 

Restraint Data Item 13:  Logic Duration (Lag) transferred or calculated from the keyed logic duration.

 

Restraint Data Item 14:  Keyed Logic Duration (Lag) Calendar may be any of the activity calendars or may be linked to the default logic duration calendar (“_” or blank) as per user set-up, the calendar of the predecessor activity or event (“<”,) or the calendar of the successor activity or event (“>”) or the “24/7/365” all-time-unit calendar (“^”.) 

 

Restraint Data Item 15:  Logic Duration (Lag) Calendar transferred or calculated from the keyed logic duration calendar.

 

Restraint Data Item 16:  Logic Duration Code P/C/K is pre-set by choice of Logic.  For FS, SS, FF or SF logic, the code is pre-set as “C” or “Clocked” based upon clocked time units from the finish or start or the predecessor activity.  For PS logic the code is pre-set as “P” or “Progressed” based upon the progress measured by OD – RD of the predecessor activity.  For FP logic the code is pre-set as “P” or “Progressed” based upon the progress measured by OD – RD of the successor activity.  “K” is not a supported option.

 

Restraint Data Item 17:  Logic Duration Code C/I/S is pre-set by choice of Logic.  For FS, SS, FF or SF logic, the code is pre-set as <<< >>>

 

Restraint Data Item 18:  Logic Duration Code M/R/P is user selected to address how calculations should proceed in the case where progress is reported out-of-sequence.  For PS and FP logic, the code is pre-set to that of the predecessor or successor respectively.  For FS, SS, FF and SF logic, such may be user defined.  A default setting should be available to set such code based upon the similar code chosen for the predecessor activity. 

 

include:

 

 

LDurCode P/C/K

 

 

Progressed

Progress is calculated by OD – RD (= Original Duration – Remaining Duration)

 

Clocked

Progress is calculated by DD – AS (= DataDate – Actual Start)

 

Clock-but-checK

Progress is calculated by DD – AS ≥ 1, reduction from 1 requires RD = OD

 

 

 

 

LDurCode C/I/S

 

 

Continuous

ES calculated from predecessor only

 

Interruptible

ES is later of that calculated from predecessors, or EF – RD

 

Stretched

ES is later of that calculated from predecessors, or EF – RD but EF – ES ≤ OD + x%

 

 

 

 

LDurCode M/R/P

 

 

Modified Logic

Activities started out-of-sequence may continue, but not be calculated as completed

 

Retained Logic

Activities started out-of-sequence may not continue until all predecessor complete

 

Progress Override

Activities started out-of-sequence may continue without regard to predecessors

 

 

 

 

 

 

 

Restraint Data Items 19 – 20:  Keyed Optimistic and Pessimistic Logic Durations (Lags) may be a specified number of time units or may be referenced to the reference activity of the restraint, i.e. to the predecessor activity for logic codes FS, SS, FF, SF or PS, to the successor activity for code FP.  Where so referenced, the keyed duration may be expressed as a percentage (e.g. -15% or +20% ) or fractional value (e.g. -65/72 or +92/72, based upon user defined units of performance) of the reference activity duration.  Thus for logic types FS, SS, FF, SF and PS, the percentage or fraction relates to the original duration of the predecessor; for logic type FP the percentage or fraction relates to the original duration of the successor. 

 

Restraint Data Items 21 – 22:  Optimistic and Pessimistic Logic Duration (Lag) transferred or calculated from the keyed optimistic or pessimistic logic duration.

 

Restraint Data Item 23:  Relationship Code is calculated for each activity code and event code based upon comparison of predecessor and successor activity or event to each restraint.  Choices are “N/A – no comparison,” equal, not equal, less than, and greater than.  (Codes:  _/=/≠/</>). 

 

Restraint Data Items 24 – 29:  Calculated ES, EF, LS, LF, JS, JF for the restraint. 

 

Restraint Data Items 30 – 34:  Calculated Total Float, Normalized Total Float (based on 24/7/365 calendar,) and Just-in-Time Total Float and Normalized Just-in-Time Total Float.  Note that restraints (which have an event at the beginning and end do not have events embedded within) do not have separate Start-Total-Float and Finish-Total-Float.

 

 

 

<<< end of text