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 IDs 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:
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:
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 users 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 IDs 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:
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 IDs 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 IDs 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:
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:
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:
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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||