"Checks and Balances: Baseline Schedule Review"
|
|
Presened 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.
|
|