"Checks
and Balances: Baseline Schedule Review"
|
|
Presented at the
2002 Primavera Users Conference
|
|
Copyright 2002 by
Ron Winter, Ron Winter Consulting LLC
|
October 22, 2002
|
|
The
Importance of a Good Baseline Schedule
|
|
Good
and timely Baseline Schedules are extremely important to a successful
construction project. The acceptance of a Baseline Schedule legally
constitutes an amendment to the basic contract. It is possible to wave
contractual requirements just by allowing items in the Baseline Schedule that
contradict what is specified in other documents. On the other hand, the
Spirit of Partnering requires that you not arbitrarily reject a schedule just
because of minor, inconsequential deviations from the specifications.
|
|
When
I am called upon to analyze a submitted Baseline Schedule, I am not looking
for the ‘perfect’ schedule, just one that is as useful as possible for the
purposes intended (including legal.) The schedule must meet any constructive
specification but requirements must not be insisted upon unless the method
being presented by the contractor is clearly wrong.
|
|
Some
review techniques can be best described as “soft;” schedules should be
complete and constructible, proper allowance should be made for activities
affected by seasonal issues. Quite often, there is not clear ‘right’ or
‘wrong’ inclusion and these issues are not easily subjected to automation.
|
|
In
this presentation, I am going to describe 110 specific types of checks or
analyses that you should perform when reviewing a Baseline Schedule. There
are plenty of checks that will be useful to Beginners and I am sure that I
perform more than a couple of checks that will intrigue Experts.
|
|
It's
tough to know where to begin when someone hands you a brand new Schedule to
review. Most people first consider one angle and then another, throw the
package in the In Basket and go to lunch, hoping that it will mysteriously
disappear before you get back. Not me (any longer.) Let me tell you why with
the ultimate rule, Step 1.
|
|
|
But
I won’t stop there. Explaining what to look for is not sufficient. You need
to understand the reason behind each check. I am not only going to tell you
WHAT to look for, but also WHY and what could happen if you don’t.
|
|
|
It
is important that a reviewer not just use a couple of tools when performing a
Baseline Schedule check but that he throws the entire toolbox at it and that
he does this every time. But being complete and through is difficult and
time-consuming to do. That is why I wrote Schedule Analyzer Pro Baseline
Checker to automatically do the tough and boring stuff, leaving the Scheduler
to do the thinking and determine what it all means.
|
|
STANDARDS
|
|
|
New
to Schedule Analyzer Pro Baseline Checker is “Standards Checking.” Many
people say that they have Company Standards or Personal Standards that they
consider whenever reviewing a schedule. This concept is especially important
for managers overseeing Capitol Improvement Programs.
|
|
|
Why
are Scheduling Standards important? The easy answer is “to maintain quality
control from one project to the next.” A better answer is to implement
‘lessons learned’ on past projects so you don’t have to sweat through that
same problem on this project. In addition, standardized schedules allow for
historical cross-reference and meaningful comparisons.
|
|
|
How
to define your standards? The simplest way is to say that all schedules
should look just like our ‘Standard Schedule,’ regardless of the project,
size or type. Look to see if there is a pattern of use for a particular topic
in the Standards Schedule. If so, look to see if that standard is violated in
the schedule being checked.
|
|
|
A
‘Standards Violation’ isn’t necessarily “bad.” It is up to you to determine
for yourself what any particular deviation from your standards means. The
important thing is to know about the discrepancy. You can’t handle an issue
that you don’t know about.
|
|
|
The
flowing standards checks should be made on each schedule that is checked:
|
|
Statistical
|
|
Does
the project use Imposed Finish Dates? Does the project use the same calendar
start date? Does the project start on the same workday? Does the project use
the Company Name Field? Does the project use the Project Name field? Does the
project use the Report Title field? Does the project use the same Calendar
Numbers? Does the project use the same Calendar Holidays? Does the project
use the Rules Description field? Does the project use the Rules Date field?
Does the project use the same Autocost Rules settings? Does the project use
the same CPM Rules settings?
|
|
Activities
|
|
Does
the project require all Activity IDs to be Numeric or Alpha? Does the project
require the leading character in the Activity ID to be a letter? Does the
project require all Activity IDs to be the same length? Does the project
allow Activity IDs to have embedded spaces? What is the maximum duration
allowed? Are any of the Types of Activities not used? Does the project allow
Task Activities to have zero Original Durations? Does the project have
smaller ratio of critical and near-critical activities? Does the project
require Activity Descriptions to be left-justified? Does the project require
all Activity Descriptions to be unique?
|
|
Codes
|
|
Does
the project use Activity ID Codes? Does the project use the same Activity ID
Code Field Definitions? Does the project use the same Activity ID Code
Instance Descriptions? Does the project allow blank Activity ID Codes to be
used? Does the project use Does the project use Activity Codes? Does the project
use the same Activity Code Field Definitions? Does the project use the same
Activity Code Instance Descriptions? Does the project allow blank Activity
Codes to be used? Does the project use WBS Codes? Does the project use the
same WBS Definitions? Does the project use the same WBS Titles? Does the
project allow blank WBS to be used?
|
|
Relationships
|
|
Does
the project use all four of the possible relationship types? Does the project
use negative lags? What is the maximum allowable lag used? What is the
minimum allowable lag used? Does the project use SS and FF relationship
pairs? Does the project use relationship pairs other than SS/FF? Does the
project use more than two relationships between the same activities? Does the
project have more than one activity with no predecessor? Does the project
have more than one activity with no successor?
|
|
Constraints
|
|
Does
the project use any of the 11 possible constraints?
|
|
Cost
|
|
Does
the project use Costs for Task type activities? Does the project use Costs
for Milestone and Flag type activities? Does the project use Costs for
Hammock and WBS type activities?
|
|
Logs
|
|
Does
the project use Log records?
|
|
SPECIFIC
BASELINE CHECKS
|
|
|
I
try to make the scope of these categories as specific as possible in order to
understand what the change means. For example, instead of looking at all
duration changes, I might be just interested in those activities that have
not started as yet whose duration has changed. Then I look at a similar,
related category of issues.
|
|
|
The
following list includes 25 pre-analysis checks, 33 activity checks, 22 coding
checks (Activity ID, Activity Code, & WBS,) 17 logic relation checks, 8
constraint checks, and 9 cost checks. I organize my analysis this way to
‘break-down’ the various occurrences into categories. I find it easier to
understand a topic if I deal with all instances of a particular issue and
then move on to the next issue.
|
|
1.
[Pre-Analysis Checks] Check to see if CPM calculation has been made. Check
for proper Company Name, Project Title [Legally, proper, complete titles are
important for later identification. Your documents may end up in a big box
with reports from other projects and some poor slob on a Claims Analysis Team
will be trying to separate out the project being investigated. You should
have unique identifier so that any report or plot made will be admissible in
court (ie. “Caltrans Project #11-234567”) instead of “Alameda Project.”],
Report Title, Project Version (should say “Baseline.”)
|
|
2.
CPM should be calculated (can’t if logic loops were never cleared.)
|
|
3.
Imposed Finish Date (this is a poor idea.) Look for imposed finish date.
Better to constrain final activity directly. Otherwise problems with work
after Substantial Completion.
|
|
4.
Data Date should equal project start should equal NTP. Look for being the
same, should be NTP unless scheduled work prior to this explain what is data
date & how it should advance with every update. Whatever status is in the
Accepted Baseline Schedule becomes the ‘baseline’ and not normally part of
any delay.
|
|
5.
Calendar Type (should be appropriate (i.e. days/hours) HOURS: It is difficult
to use this small of a duration on long projects. Unless you are scheduling a
short-duration shut-down project where status is taken each hour, it is
better to schedule most projects in days. The only way to change this unit of
measurement is to copy the schedule and define the new unit during the
process. DAYS: This is the standard setting, offering a balance between
accuracy and maintainability.
|
|
6.
Start Day Setting: The start day for the week is used for reporting on a
weekly timescale and to determine when weekends occur for Calendar 1. This
setting can be changed once defined by selection Data, Calendars, Global
Calendar, Standard.
|
|
7.
Calendar Check : Look for odd weekend (not sat, sun). Look for no names for
calendars. Look for 7-day/week calendar (cure concrete). Review all calendars
for consistency (should have same holidays except were specificity different,)
Global cal should not have holidays (can’t make a 7 day/week calendar without
resorting to exceptions. Look to see Exceptions are implemented correctly
(and not as additional holidays.) Look to see all calendars cover entire
project (calendars are not additive.) Check for superfluous Exceptions or
Holidays before Project Start. Compare holidays with specified holidays.
Check that the holidays on weekends are properly set with the Holidays
Advanced/Delayed setting. Improper use of repeating holidays.
|
|
8.
Rules Set & Rules Date fields entered (shows last date the rules were
checked QC).
|
|
9.
'Rule #1: Link remaining duration and schedule percent complete. Perform this
check even if no costs. Yes is the standard setting and should be used unless
using nonlinear resource distributions. Others say No should be used as it is
more accurate. I say too easy to miss in an update if not automatic.
|
|
10.
Rule #2: Freeze resource units per time period? Yes is the standard setting
and should be used unless workcrews are varied in size in response to earned
progress so as to meet planned finish.
|
|
11.
[COST ONLY]Rule #3a: Calculation for estimate to complete? Add actual to EAC
is used on cost-plus contracts, as it allows you to exceed your budget.
Subtract actual from EAC is used on fixed-price contracts, as it doesn't
allow you to exceed your budget."
|
|
12.
[COST ONLY] Rule #3b: Allow 'negative estimate to complete'? " No: With
this setting, P3 will not allow a negative calculation Instead, it will automatically
set 'Estimate to Complete' = 0 and change your 'Estimate at Completion' =
'Actual to Date.' With YES: A negative estimate to complete indicates an
over-budget situation, but will not automatically modify other values.
|
|
13.
[COST ONLY] Rule #4a: When Quantities change, recompute Budget Costs? No is
the standard setting. Use this when you do not track costs or when the budget
is known. YES is only use this setting when tracking costs but the budget has
not been set.
|
|
14.
[COSTS ONLY]Rule #4b: When Quantities change, recompute Actual Costs? No is
the standard setting. Use this when you do not track costs or when Actual
Costs are known. YES: Only use this setting when tracking costs but Actual
Costs are not tabulated. It is dangerous to estimate actuals."
|
|
15.
[COSTS ONLY] Rule #4c: When Quantities change, recompute Est. to Complete
Costs? No: CAUTION: Only use this setting when the cost to complete is not
related to the quantity remaining or unit price. Yes: is the standard
setting. Estimates to complete should be related to quantities remaining.
|
|
16.
[COSTS ONLY]Rule #5a: Update % complete against budget to recompute Budget?
No is the standard setting. This prevents P3 from automatically modifying
your budget. Yes: CAUTION: Only use this setting when tracking costs but the
budget isn't fixed.
|
|
17.
[COSTS ONLY]Rule #5b: Update % complete against budget to recompute Cost? No
is the standard setting. Use this when you do not track costs or when Actual
Costs are known. Yes: CAUTION: Only use this setting when tracking costs but
Actual Costs are not tabulated. It is dangerous to estimate actuals.
|
|
18.
1. COSTS ONLY]Rule #6: Actual linked to date and actual this period? No: Use
this setting if you do not intend to track costs per update period. It might
speed up operation of the program. Yes:: Use this setting if you are tracking
costs per update period.
|
|
19.
[COSTS ONLY]Rule #7: Budget linked to EAC for non-progressed acts? No is the
standard setting once a budget has been set. Yes; CAUTION: This setting
should only be used during the planning stages of a project. Until set to
off, P3 will not calculate variance.
|
|
20.
[COSTS ONLY]Rule #8: Variance is calculated as: "Estimate At Completion
- Budget." NOTE: This method displays budget overruns as positive
values. "Budget minus Estimate At Completion.": This is the default
setting that displays variances as negative values.
|
|
21.
[COSTS ONLY]Recalculate and Store Cost during each schedule computation? No
is the correct setting if your project does not calculate costs or if it does
not use non-linear resource distributions or costs associated with Hammocks
or Expected Finish Constraints. Yes is the correct setting if your project
uses costs and non-linear resource distributions or assigns costs to Hammocks
or activities using Expected Finish constraints.
|
|
22.
Apply the above rules by Cell or Resource? Cell is the default setting. It
will register your entries as you move your cursor from field to field.
Resource setting will speed-up updates. It will not change the results of any
calculations.
|
|
23.
[CPM RULES]Scheduling Method is set to Retained Logic. is the normal method
for predicting status with out-of sequence progress. Progress Override is
only allowable when logic is only used to sequence activities and not to show
interdependencies. This method assumes that once you start an activity, that
you may continue working on it without concern for uncompleted predecessor
activities. This will 'collapse' a schedule. Some contractors use this to
allow them to manage ongoing tasks ‘without interference from management.’
|
|
24.
SCHEDULING METHOD: Contiguous Activities. CAUTION: This is the standard
setting but will produce different results for activity chains identified in
later Interruptible Activities Report. Use this setting for projects that
wait until all resources may be employed without a break. Interruptible
Activities.: NOTE: This is not the default setting, but a better choice for a
select few activities identified in the Interruptible Activities Report. Use
this setting for projects where work is aggressively pursued, starting
whenever it is possible without regard to maintaining a steady, contiguous
work flow.
|
|
25.
Total Float Calculation uses Finish Dates/Start Dates/Most Critical Dates to
calculate Total Float. NOTE: This will result in the same answer except for
interruptible activities and Hammock activities. Interruptible activities
work better using Finish Dates and Hammock activities work better using the
Start Dates setting.
|
|
26.
[ACTIVITIES] Bogus dates: Bogus means that they shouldn’t be allowed under
any circumstances. Missing Early & Actual Start Dates. Missing Early
& Actual Finish Dates. Finish date more than one day earlier than Start
date (negative duration.)
|
|
27.
Review proper use of Activity Types: Task, Independent (common if came from
SureTrak,) Meeting, Start milestone, Finish milestone, Start flag, Finish
flag, Hammock, WBS (can’t use in time-scaled network plots)
|
|
28.
Bogus: no actual start with progress registered.
|
|
29.
Bogus: no actual finish and 100% complete.
|
|
30.
Bogus: actual finish date and incomplete.
|
|
31.
Bogus: actual dates before project start.
|
|
32.
Total number of activities. CAUTION: Many contracts specify the maximum or
minimum number of activities allowed in the schedule. For this purpose, Fixed
and Resource-Driven Duration Activities are usually totaled.
|
|
33.
Negative Float: Baseline schedules should never have negative float. This
means that the schedule does not meet contractual requirements.
|
|
34.
Early Completion Schedule: This could mean that the Contractor is declaring
their intent to complete this project early. If sustained, the Owner might be
liable for additional costs associated with delays, even if the project
finishes on or before the original required completion date.
|
|
35.
Percentage of activities that are critical or near-critical: Many
specifications limit the percentage of activities that can be critical or
near-critical in the Baseline Schedule. A typical upper limit is a maximum of
30% critical and 50% critical or near-critical. Near-critical may be any
float equal or less than 10 (although this is not a set rule.)
|
|
36.
ACTIVITY ID CODING CHECK: Look for Alpha-Numeric not left justified (Apparent
numeric but is not.) Look for if Alphanumeric, than ID starts with a letter.
Look for Numeric IDs not right justified. Look for spaces in Ids. Pros/Cons
of numeric Ids. NOTE: Experienced Schedulers tend to not use numeric Activity
IDs but use a combination of letters and numbers. P3 automatically right-
justifies numbers (by padding the left with blanks.) Any IDs added with
letters are left-justified, making a confusing and jumbled look to any
listing. Recommend that you begin IDs with a letter.
|
|
37.
Activity Duration Checks: Look for longest acts and ask if they are within
spec limits. Consider a histogram of number of acts and their durations as a
way to ‘see’ distribution as well as just numbers. NOTE: Many contracts
specify the minimum or maximum allowable durations of activities included in
the schedule. It is best to not consider milestones or summary activities
when qualifying durations.
|
|
38.
Long Task Durations (Don't apply this test to resources or summaries) Case
"Hours": Odd = 40, Case "Days": Odd 20, Case
"Weeks": Odd = 10, Case "Months": odd = 4. CAUTION: Many
specifications require activities to be defined with durations less than a
set number. The intent of this requirement is to allow for better monitoring
and control of the work described by the activity. Typically, the reviewer is
allowed to wave this requirement in the case of Hammocks or deliveries, etc.
|
|
39.
Suspicious Task duration values (example: if Days; more than 7, not in
multiples of 5 or 7) '(Don't apply this test to resources or summaries) Case
"Hours": Default = 8/16. Case "Days": Default = 5/7. Case
"Weeks": Default = 4/52. Case "Months":' Default = 4/12.
CAUTION: Some schedulers arbitrarily modify activity durations to make
various near-critical logic chains match total durations exactly, thus
artificially producing multiple critical paths. The above listed activities
have 'odd' durations, which should be investigated further, especially if
they are critical.
|
|
40.
Suspicious Remaining Durations: Unstarted activities should have Original
Duration = Remaining Duration. Remaining Duration should never be greater
then Original Duration without an explanation.
|
|
41.
Actual dates in baseline schedule. CAUTION: Baseline Schedules should not
contain actual dates (except for Notice To Proceed, if already passed.)
Otherwise, you risk having poorly performing activities accepted as part of
the Baseline and not as part of the history of the project.
|
|
42.
[DESCRIPTION CHECKS]ACTIVITIES MISSING DESCRIPTIONS: CAUTION: All activities
should have descriptive titles. This title serves as a form of Scope Of Work
definition and thus further defines the contract.
|
|
43.
Look for Notice To Proceed or an UNUSUAL NUMBER OF 'NOTICE TO PROCEED'
ACTIVITIES. CAUTION: If there does not appear to be a Notice To Proceed in
this schedule. All projects run under the concept of "Time Is Of The
Essence" require a formal declaration of the start of the project.
|
|
44.
Look for Mobilization or an UNUSUAL NUMBER OF 'Mobilization ACTIVITIES.
CAUTION: If there does not appear to be a Mobilization in this schedule. It
is often required by specification, or specifically called out as a pay item,
and can be important legal point in delay disputes.
|
|
45.
Look for Substantial Completion. See if coded as milestone (if not 0
duration, confusion as to start or end of act) calculate calendar days from
NTP & ask if this meets contractual completion (also mention early
completion problems.) NOTE: It is best to schedule a project so that the
early computed completion date exactly matches the contractually required
completion date. Then, if either party delays the project past that time, the
delaying party pays compensation for the delay to the other party. CAUTION:
If the Owner accepts a schedule that shows an early completion finishing
later than allowed by contract, it MAY mean that the Owner forfeits the right
to assess Liquidated Damages until after the early finish in the accepted
baseline schedule. Generally, to be valid, the Contractor must also
specifically state that they intend to complete the project early. CAUTION:
If you accept a schedule that shows an early completion date earlier than the
required completion date as specified by contract, it often means that the
Owner must compensate the Contractor for Owner's Delays to the project even
if that delay did not cause the project to finish past the original required
completion date. CAUTION: If there is no Substantial Completion in this
schedule, it will still exist. Regardless of whether it is called out by specification,
it is widely recognized legally as the termination point for the assessment
of Liquidated Damages and thus should be included. ERROR: Substantial
Completion activities should be milestones and never have duration; otherwise
confusion can result as to the legal date of the completion of the liquidated
damages.
|
|
46.
Look for Beneficial Occupancy, Occupy, etc. If found, explain that you
shouldn't have both BO & SC (confusion). CAUTION: Any occupancy of the
contracted structure may be considered a case of Beneficial Occupancy.
Beneficial Occupancy legally marks end of Liquidated Damages, even if the
project is not complete. ERROR: Any occupancy of the contracted structure may
be considered a case of Beneficial Occupancy. Beneficial Occupancy overrides
Substantial Completion in determining the end of the period of Liquidated
Damages.
|
|
47.
Activities with work percentages in their title. CAUTION: These types of
activities that are described in terms of a percentage of a task is poor
scheduling practice as it cannot be accurately statused. We suggest that you
use physical lengths of progress such as "INSTALL CULVERT, 0 - 100
METERS" or ”POUR FOUNDATION, 1-3 GRIDLINE".
|
|
48.
Look for "REVIEW" or "APPROVE" activities. Identify any
activity that involves the Owner or Architect. Are durations according to
specs min? Is contractually required time provided? CAUTION: You should check
the these activities to ensure that the time allotted is within the specified
minimums. You should also scrutinize any activity that lists work
responsibilities for the Owner or A/E as this might compromise you legally
later. CAUTION: It is in the Owner's and Contractor's best interests to
include all significant submittals in the schedule. It serves as a checklist,
helping the Contractor to remember this important task. More importantly, the
Submittal-Review-Deliver process frequently impacts the critical path of
projects with major items to install. CAUTION: You may have submittal
activities but they do not say 'SUBMIT.' Sometimes the schedule will just
say, 'HVAC DRAWINGS'. This is not enough as it may or may not include the
review period. Suggest that you require 'SUBMIT' and 'REVIEW' as separate and
distinct acts.
|
|
49.
Look for INSPECT activities. CAUTION: You should check these types of
activities to ensure that the time allotted is within the specified minimums
and that such activities are scheduled based on workday (not weekend)
schedules.
|
|
50.
Look for UTILITY activities. CAUTION: Typically, utility companies are considered
'third-parties.’ They are not under the control of either the Owner or
Contractor. Delays caused by the utility company are typically considered as
excusable and sometimes compensible by the Owner, even if the owner had no
direct hand in the cause. Check to see that the time allowed is per
specification. Ideally, it would be nice to not have these activities not on
the critical path, but often they are.
|
|
51.
Major materials purchase and delivery. CAUTION: You should check the above
activities to ensure that all important pieces of long-lead items are
accounted for. You should also check that such activities are scheduled based
on 7-days per week (not workday) schedules. Each should lead to the
appropriate place in the schedule where it is needed.
|
|
52.
Look for TEMPORARY activities. Sometimes, Contractors propose temp measures
that are not allowable. CAUTION: You should check the above activities to
ensure all proposed actions are acceptable. Sometimes, Contractors plan to
create temporary barriers, access points, or structures that would conflict
with Owner Operations or safety rules in effect.
|
|
53.
Possable Exceptional Activities. CAUTION: You should check the above
activities to ensure all descriptions are objective and not prejudicial or
inflammatory. Acceptance of a schedule with descriptions of delays that blame
the Owner may be construed as acceptance for the responsibility of that
delay. Also, there is not room for profanity in a schedule.
|
|
54.
Look for duplicate activity descriptions. CAUTION: Activities with duplicate
descriptions are confusing to track. Even though they may be coded for
different areas, this is not always clear on print-outs. Suggest that you
start each description with 'AREA A - (description)' instead.
|
|
55.
Look for milestones coded as activities (Zero duration activities.) NOTE: The
above activities should have durations or be coded as milestones. Otherwise
you have to deal with an early finish that is earlier than the early start
and that can give you headaches.
|
|
56.
Are all contractual milestones identified? Are all that are present part of
the contract? NOTE: The only milestones that should be in a Baseline Schedule
are contractually required ones. Verify that the above list is reasonable and
inclusive.
|
|
57.
Consider creating an Activity Distribution Histogram. Lay out # of active
acts per time period (I use 50% of the float.) NOTE: You should confirm that
the schedule is roughly equally detailed from the start to the finish of the
project. The above curve should be somewhat flat and balanced on both ends. A
lower second half might indicate an under-developed finish plan.
|
|
58.
[ACTIVITY CODE ANALYSIS] Are Activity ID Codes used? NOTE: Activity ID Fields
are reserved parts of the Activity ID that can be used to group related
activities. Typically, Alpha/Numeric ID is used and the first 1 or 2 spaces
are used to define Areas, Phases, etc. This older technique is now less
favored than the use of more versatile Activity Codes.
|
|
59.
Are Activity Codes used? CAUTION: It is strongly recommended that you use
Activity Codes to help you manage you schedule database. You can group
activities by Area, Responsibility, Phase, or any other user-defined heading
that you wish. Set up your activity codes under Data, Activity Codes.
|
|
60.
Are Activity Code Definitions defined? ERROR: Code Field Definitions are
automatically used in plot legends and whenever you ask for help while using
this field. If you are not using this field, suggest that you delete it to
make the files smaller.
|
|
61.
Look in Activity ID Code dictionary for blank descriptions. This can occur
when the auto-insert feature is on and the User enters the wrong code for an
activity. Identify the activities so coded and put in the correct code.
|
|
62.
Look in Activity Code dictionary for blank descriptions.
|
|
63.
Look in Activity ID Code dictionary for duplicate descriptions. ERROR: The
same code field description has been used for two different codes in the same
category. One of these should be deleted. And the activities updated.
|
|
64.
Look in Activity Code dictionary for duplicate descriptions.
|
|
65.
Use of Reserved words as Activity ID Codes or Activity Codes. ERROR: P3
reserves words such as the one used above to mean something else than your
Activity Code. It cannot distinguish between the two when programming a
global change or a report specification. You must change this code. Reserved
words are: 1EF, 1ES, 1LF, 1LS, 2EF, 2ES, 2LF, 2LS, ACC, ACT, ACX, AD, ADUR,
AF, ANO, AS, BC, BCWP, BCWS, BLNK, BQ, BQWP, BQWS, C1EF, C1ES, C1LF, C1LS,
C1OD, C1RD, C2EF, C2ES, C2LF, C2LS, C2OD, C2RD, CAC, CAL, CAT, CON, COND,
CONT, CTC, CTD, CTP, CV, CVAR, CVQ, DD, DES, ECON, ED, EF, ES, FD, FF, FFL,
FM, FNE, FNL, HA, LCON, LD, LF, LOG, LPTH, LTYP, LS, MEM, MF, MIL, MS, NACT,
NRES, OD, ON, PCT, PNO, QAC, QTC, QTD, QTP, QVAR, RD, RDRV, RDUR, RES, RID,
RLAG, RPCT, RSM, RUM, SD, SF, SM, SNE, SNL, SNO, SUS, SV, SVQ, T1AF, T1AS,
T1EF, T1ES, T1LF, T1LS, T1OD, T1RD, T2AF, T2AS, T2EF, T2ES, T2LF, T2LS, T2OD,
T2RD, TF, UPT, V1EF, V1ES, V1LF, V1LS, V2EF, V2ES, V2LF, V2LS, WBS, XF, ZFF,
ZTF, STYP, WBST.
|
|
66.
Look for unregistered Activity ID Codes.
|
|
67.
Look for unregistered Activity Codes. ERROR: You can have P3 automatically
validate added Activity IDs to verify that the Activity ID Code matches one
in the dictionary so that you do not have this situation.
|
|
68.
Look for blank Activity ID Code fields. Can happen if numeric ID is entered
(right justifies.)
|
|
69.
Look for blank Activity Code fields. If not used, delete code definition. If
not pertinent, define a N/A definition so that you do not have a gap on plots
or reports. ERROR: It is easy to miss entering a code field when building a
schedule. It is important that all activities have a code so that they won't be
overlooked in reports, filters, and views. Suggest that you look for a
similar activity and use the code found there. If no code applies, consider
'GENERAL' or 'OVERVIEW.'
|
|
70.
Suggest that you create Expanded Activity ID Field Layout. This lists each
Code ID Field, each of the values with descriptions and the number of
activities that fall into each category. This will show you if you missed
including activities for a particular category or if the coverage is
unbalanced.
|
|
71.
Suggest that you create Expanded Activity Code Field Layout. This lists each
Code Field, each of the values with descriptions and the number of activities
that fall into each category. This will show you if you missed including
activities for a particular category or if the coverage is unbalanced.
|
|
72.
Check for Work Breakdown Structure definition. NOTE: Use of WBS assignments
is becoming increasingly more prevalent, especially in large, enterprise
scheduling situations. It has the built-in ability to summarize groups of activities
without adding additional logical relationships, such as required by
hammocks. It has the weakness of not being supported in Time-scaled Network
Diagrams and for some types of reports.
|
|
73.
Activities Improperly Coded As Wbs Hammocks. ERROR: Activities coded as WBS
will not behave like CPM activities, even if you include relationships and
durations. Remove this type coding or define and use WBS Levels.
|
|
74.
Confirm that all WBS levels are fully defined and not blank. CAUTION: Missing
WBS Definitions will lead to confusion and possibly a failure to correctly
account for work or costs properly.
|
|
75.
Are all WBS-Type acts identified with a WBS code? WBS-Type activities with no
corresponding activities with that WBS code will act like a hammock without
activities. ERROR: This type of activity summarizes all other activities with
an identical WBS code. The above activities summarize nothing.
|
|
76.
Are all activities included with WBS codes?
|
|
77.
Are all WBS codes used in the dictionary? ERROR: Undefined WBS Codes usually
occur due to an error in input. Correct these codes or add them to the WBS
Directory, as appropriate.
|
|
78.
Suggest that you create Expanded WBS Field Layout. This lists each WBS Field,
each of the values with descriptions and the number of activities that fall
into each category. This will show you if you missed including activities for
a particular category or if the coverage is unbalanced.
|
|
79.
[RELATIONSHIP ANALYSIS] Check for proper coding of Hammock Activities. Each hammock
should have at least one SS predecessor & at least one FF Successor.
Anything else does not perform any purpose in the schedule. They do not
summarize anything and cannot be used as regular CPM activities. Add the
necessary Start-To-Start or Finish-To-Finish coding or remove the activity
from the schedule.
|
|
80.
Hammock activities with ignored relationships. Any other relationships &
lags are not used and ignored (except for plotting purposes - technique used
for roll-up summaries.) CAUTION: The above activities use relationships and
lags that are ignored by P3 when computing the network. NOTE: Some schedulers
include Finish-to-Start relationships to Hammocks as a trick to make P3 plot
the network logic when presenting a summary-level schedule showing Hammocks
without the underlying activities. This is reasonable. Use of Lags and
Start-to-Finish relationships are still of questionable value and might
mislead.
|
|
81.
Activities logically after substantial completion. Look for landscape
maintenance after SC. Look for punchlist after SC (not before.) CAUTION: The
schedule represents tasks necessary to satisfy the contract. Normally, any
activity after Substantial Completion is legally free of penalties for late
completion. Confirm that the activities listed above fit into this category.
|
|
82.
Late activities not logically tied to substantial completion. CAUTION: Tasks
occurring after Substantial Completion typically are related to this
activity. It is generally allowable to have tasks that do not have
successors, but it is assumed that each will complete before Substantial
Completion. These tasks can show very incorrect float if there is an
allowable activity after substantial completion (like landscape maintenance)
that extends the completion of the schedule.
|
|
83.
Activities logically prior to mobilization. CAUTION: Some projects get off to
a bad start when the Contractor fails to mobilize on the construction site in
a timely manner. There should be no logical reason in the schedule for the
Contractor to delay mobilization other than issuance of the Notice To
Proceed. CAUTION: Mobilization should logically follow some authorization to
be on the site, such as an issuance of a Notice To Proceed.
|
|
84.
Activities logically before notice to proceed. NOTE: Normally, the Contractor
is not authorized to perform any paid tasks prior to the Notice To Proceed.
You should review the above list to avoid authorizing early work or even
unintended NTP.
|
|
85.
Early activities not logically tied to notice to proceed. CAUTION: Check to
see that the schedule does not authorize the Contractor to perform tasks
before the Notice To Proceed. This can happen when an activity is missing any
predecessor relationships.
|
|
86.
Submittal activities without successor review activities. CAUTION: Every
submittal activity should normally be immediately followed by a review
activity. This ensures that sufficient time is allotted between the submittal
and the need for the submitted items. The review activity should have a
delivery or actual use successor.
|
|
87.
Multiple, simultaneous near-critical path activities. CAUTION: CPM networks
should not have multiple critical paths without through justification. Some
Contractors adjust durations, logic, and lead times so as to artificially
create multiple paths. This increases the number of critical activities that
increases the potential that any Owner-caused delay will look like a delay to
the project. Detail analysis of the above activities is recommended.
|
|
88.
Active activities with interruptible logic relationships. Look for activities
with both SS & FF predecessors to same activity and a single SS
relationship to a successor activity. ERROR: This project calculates the
above logic chains as Continuous. This is only appropriate if the Contractor
does not begin work on tasks until they are able to finish the task without
stopping. This precludes early starts. Otherwise, follow-on tasks will be
scheduled to begin later than will probably occur. CAUTION: The above
relationship chains are logically interruptible. The schedule is configured
to allow Interruptible Activities. This will result in the automatic
stretching of the duration of the second activity listed in each logic chain
pair displayed above.
|
|
89.
Report on any Start-To-Finish Relationships. NOTE: There are a total of 4
'legitimate' relationships that can be used. Finish-to-Start (FS) is the most
common, followed by Start-to-Start (SS) and Finish-to-Finish (FF.) A
Start-to-Finish (SF) relationship would mean that the succeeding activity
couldn't finish until the preceding activity started. CAUTION: It is highly
unusual to use Start-to-Finish (SF) relationships in a schedule. Recommend
that you confirm that this was intentionally used and not an entry error.
|
|
90.
Multiple Relationships. Activities can have up to 4 different relationships
between each other at the same time. For my money, if any activity pairs have
more than one relationship, it should only be a Start-To-Start and a
Finish-To-Finish pair. Any other combination is unusual.
|
|
91.
Many people believe that all activities should have a relationship that
defines the requirements for finishing that activity. This means that
activities should have a Finish-To-Start or Finish-To-Finish relationship
with another successor activity. If not, then there will be no CPM
requirement for activity completion once it starts (other than project
completion.)
|
|
92.
Lag and Lead Checks. SS & FF should only have positive leads. FS should
not have positive leads (greater than 0.) All leads are suspect if greater
than Case Hours: Odd = 8, Case Days: Odd = 5, Case Weeks: Odd = 2, Case
Months: Odd = 1. Leads are legitimately used to describe linked activities
that are staggered or to represent a time interval, say for curing concrete. They
can be used to 'hide' float or otherwise artificially expand a project
schedule without being visible on plots or in most reports. Negative lags can
hide an unworkable project schedule by shortening it without changing
activity durations. CAUTION: It is highly unusual for Start-to-Start (SS) or
Finish-to-Finish (FF) relationships to have negative lags. Recommend further
investigation into the reasoning behind such timing. CAUTION: It is highly
unusual for Finish-to-Start (FS) relationships to have positive lags.
Recommend that you have the creator of the schedule document what that lead
represents. CAUTION: While lags and leads have legitimate uses, any such time
interval over a threshold value should be individually investigated. You must
consider the calendar when using lags. Lags use the calendar of the
proceeding act. In the case of concrete curing (a 7-day/week event,) the lag
would use the calendar of the concrete pour, which is probably a 5-day/week
event. Just expanding the length by 7/5 does not fully consider where in the
week it falls. Lags make for poor long-lead times. You cannot status a lag or
periodically review its progress. For lags of long duration (such as the
delivery of a major piece of equipment,) it would be better to create an activity
that would show-up on reports and would need to be statused every update.
|
|
93.
Besides just ‘odd’ lags and leads, most Schedulers are interested in
reviewing any relationship that uses a lag other than zero. Each such
instance should be reviewed for a reason why they exist.
|
|
94.
Non-overlapping Lag Relationships. This check entails looking for lags or
Leads greater in duration than the Activity Duration. Lags and leads
typically are used to allow related activities to overlap in time. When the lag
is larger that the activity duration, this overlap condition no longer exists
and the reason for using the SS or FF relationship disappears. If the lag
used is too great, the activities will no longer overlap in time. This may be
an entry error. Otherwise, I suggest that you convert to a different
relationship that better describes the intended relationship. Suggest that
you investigate converting to a standard FS relationship.
|
|
95.
[CONSTRAINT ANALYSIS] List all constraints. I like to see a succinct listing
of all constrained activities, the constraint and dates. The P3 CPM
calculation report is good, but it is missing the activity descriptions.
CAUTION: Baseline Schedules should only contain constraints that are
specifically called out in the plans and specifications. Otherwise, this can
be thought of as the Contractor is "reserving float" (which is
typically not allowed.) NOTE: If the Contractor resists removing
non-contractual constraints, from the Baseline Schedule, the prudent Scheduler
will note each such constraint in the review of the baseline and state that
the Owner reserves the right to temporarily delete any such constraint when
evaluating the effects of delays. Look for consistency, odd dates.
|
|
96.
Zero free float constraints. CAUTION: The above activities are being delayed
as late as possible without delaying any succeeding activities. This is
risky, as any delay in delivery will then delay work activities. Special
concern is for Owner-supplied material. Verify the reasonableness of all durations
above. NOTE: Contractors like to delay material delivery (1) to reduce
storage costs and (2) because a down payment is required and contractors like
to delay spending any money as long as possible.
|
|
97.
Zero total float constraints. CAUTION: The above activities are artificially
being coded as critical without regard to network logic. Delaying this
activity will not necessarily delay project completion. NOTE: This constraint
not only affects the above activities but all preceding activities on the
same float path. Only predecessors that were active are tabulated above.
|
|
98.
Active expected finish constraints. NOTE: Expected Finish constraints compute
remaining durations necessary to complete the activity by the specified date,
regardless of what it takes. Review the durations above for reasonableness.
CAUTION: While the employment of Expected Finish constraints is useful in
maintaining schedules, it should not be left in after the Remaining Duration
is computed, otherwise the activity duration will change unexpectedly when
you next update your schedule.
|
|
99.
Unstarted activities with expected finish constraints. CAUTION: Use of
Expected Finish constraints in this situation may indicate an attempt to
artificially inflate the duration of an activity to use all of the available
time. CAUTION: Expected Finishes should not be left in a schedule without
justification. The removal of this constraint will not change anything in the
schedule and is recommended to prevent durations from automatically changing
during updates.
|
|
100.
Active mandatory constraints. CAUTION: Mandatory Start and Finish constraints
completely override network logic and do not allow for float calculations.
Suggest that you use START ON or (better) START NO EARLIER THAN or START NO
LATER THEN constraints. NOTE: Mandatory Start and Finish constraints do not
obey CPM rules. The activity configured in this manner will be scheduled to
start on the date given even if all predecessors are not complete. START ON
constraints work the same as a MANDATORY START but also obey CPM logic rules.
START NO EARLIER THAN allows for float calculation in delay direction and
START NO LATER THAN allows for float calculation in the accelerate direction.
|
|
101.
Active start on constraints. CAUTION: START ON constraints control the start
of an activity in both the forward and backward direction. Unless absolutely
necessary, recommend the use of START NO EARLIER or START NO LATER
constraints. NOTE: START ON constraints do not allow for the activity to adjust
for changing conditions. If you want to delay the start, then use a START NO
EARLIER THAN constraint. To have an activity finish by a certain date, use a
FINISH NO LATER THAN constraint. Both allow the activity to meet restrictions
and still accommodate circumstances.
|
|
102.
[COST ANALYSIS] I am not a Cost Engineer. This is not “Accounting,” this is a
search for logical errors or oddities that you as a Scheduler had best catch
if you want to keep your job. Unused cost account codes. These account codes
were defined but unused. Perhaps an oversight. Look for Reserved cost account
codes. Just as with Activity Id Codes and Activity Codes, use of the P3
reserved words will cause problems in Global Change and in reports.
|
|
103.
Check for negative values. In order to understand the basics of Schedule
Costs, you need to evaluate three categories: Budgeted Costs, Earned Value,
and Actual Costs. None of these should be negative.
|
|
104.
Earned Value greater than Budgeted. ERROR: Earned Value is a function of a
percentage of Budgeted Costs and never be greater than 100% of Budgeted Cost.
Suggest that you investigate the above cost entries thoroughly.
|
|
105.
Actual Greater than Budgeted. CAUTION: Actual greater than Budgeted indicates
a cost overrun. You should investigate the reason for each event found.
|
|
106.
Activities with automatically adjustable durations and costs. CAUTION: The
above activities are coded as either a Hammock or with an Expected Finish.
They also have costs assigned to them. The constraints cause the activity's
duration to change when conditions in the network change. The change in
duration is applied to the unit cost, causing the costs for these activities
to automatically change as well. ERROR: If you have set Autocost Rule 8b, "Recalculate
And Store Cost during each schedule computation” to “NO," then this is
the incorrect setting for this project, as it has costs assigned to Hammock
or Expected Finish activities. The computer will not automatically ensure
that unit costs times the duration equals total costs.
|
|
107.
Totals costs per cost account. I like to accumulate and display a concise
table of accounts for the “Big Three,” Budgeted, Earned, and Actual Costs.
And then note if the grand total shows Actual greater than Budgeted costs.
|
|
108.
Check for Earned Value out of proportion. I look at activities in which
Earned Value is more than 10% different from Percent Complete. Many people
feel that Earned Value is typically a direct function of Activity Percent
Complete. When it is not, direct costs may be involved. Otherwise, you should
verify why the two percentages do not match more closely. Some variation is
to be expected.
|
|
109.
[LOG ANALYSIS] CAUTION: Activity logs can be considered a form of written
notification from the Contractor to the Owner about intent or understanding.
It is prudent to review and comment on any logs which state facts not in
agreement by both parties in order to reserve your rights later. The log
section of the schedule is an excellent place for the Contractor to further
define the parameters of each task. Here he can describe planned resource
usage, assumptions as to weather conditions, planned substitutions, and
deviations from specifications. As this is not visible in normal views and
reports, it is very typical for a Scheduler to forget to look at each log
during a review. Ignore this section at your peril!
|
|
I
perform each and every one of the above checks on every Baseline Schedule
that I review. Many Schedulers use a checklist to make sure that they don’t
forget any of their standard checks. I have something better, Schedule
Analyzer Pro. I run my Baseline Checker module on the P3 schedule and produce
a report for every time one of the above issues is found.
|
|
Before
automating this process, a Baseline Review used to take 40-60 hours. Now I
typically complete a more through analysis than I used to perform by hand in
6 - 8 hours. May all of your Baseline Schedules be perfect ones.
|
|
110.
Other Checks
|
|
There
are other items that you should check that are not so quantifiable (this is
where the 'Expert' part comes in.) Before a Baseline Check is complete, I
also refer to the following documents and issues,
|
|
*
CPM Calculation Report,
|
*
Standard Activity Listing,
|
*
Time-Scaled Network Diagram Plot,
|
*
Constructability Issues,
|
*
Access Issues,
|
*
Seasonable Considerations
|
No comments:
Post a Comment