How to build a quality, good schedule and/or plan

  • Page:
  • 1

How to build a quality, good schedule and/or plan

OFFLINE

How to build a quality, good schedule and/or plan

17 November 2011 3:23
Is there any checklist/best practices for building quality, robust and realistic schedule ?
OFFLINE

Re: How to build a quality, good schedule and/or plan

17 November 2011 3:32
You may like to refer to US Defense Contract Management Agencys 14 points but it did not format well. Some of them are: 1. No open ends (obvious).  2. No negative lags/leads (this should get some comments).  3. No durations > 21 days (would not get my vote).  4. All schedules resource constrained/loaded (does get my vote).  5. No negative float (obvious).  6. No more than 5 times as many relationship/links as activities (generous).  7. No invalid dates (again obvious).  This is just a start. Might be nice to build our own checklist because DCMA is not the final authority.
OFFLINE
Joined On:
30 Sep 2017

Re: How to build a quality, good schedule and/or plan

17 November 2011 3:36
Here is the checklist I developed sometime back -  1- A clear definition of the clients needs (owner/contractor/CM).  2- Brainstorming with key staff in different departments (financial/estimating/contracts....) regarding data sharing and expected reports.  3- Choosing the right software  4- Checking contract clauses regarding schedule requirements (resource loaded/cost integrated, time constraints, durations etc.)  5- Defining milestones to meet contract requirements  6- Understanding the construction methodology  7- Applying Pareto principle (distinguish 20% of activities which are carrying 80% of cost) from bid items  8- Establish the primitive schedule with around 50 major activities.  9- Make sure items in line 7 fit in primitive schedule.  10- Prepare a list of logical predecessors and successors to activities in primitive schedule. 11- Develop WBS  12- Define Calendars  13 - Identify Activity Codes 14 clear definition of the clients needs (owner/contractor/CM).  2. Brainstorming with key staff in different departments (financial/estimating/contracts....) regarding data sharing and expected reports.  3. Choosing the right software  4. Checking contract clauses regarding schedule requirements (resource loaded/cost integrated, time constraints, durations etc.)  5. Defining milestones to meet contract requirements.  6. Understanding the construction methodology and develop WBS.  7. Applying Pareto principle (distinguish 20% of activities which are carrying 80% of cost) from bid items  8. Establish the primitive schedule with around 50 major activities with logical predecessors and successors.  9. Are Activity and project codes identified appropriately  10. No open ends.  11. No negative lags/leads (If appropriate).  12. No durations > 21 days (TBC).  13. All schedules resource constrained/loaded.  14. No negative float (obvious).  15. No more than 5 times as many relationship/links as activities (generous).  16. No invalid dates (again obvious).  17. Appropriate Use of Calendars  18. No Un-Necessary Constraints  19. Appropriate Percent Complete Types  20. Appropriate Activity Types  21. Appropriate Duration types  22. Fixed Project Start / Finish constraints. No Dangling Constraints
OFFLINE

Re: How to build a quality, good schedule and/or plan

17 November 2011 3:32
I managed to dig one from my previous documents. 1. Project Description  • Reference Documents  o Contract  o Project Drawings  o Specifications  o Scheduling Specification  o Notice to Proceed or Release Letter  o Any Owner produced master schedule  o Liquidated Damages schedule  o Area Designation Plan  o Sequencing plan  o Estimate & quantity surveys/bills of materials  2. Schedule Specification – General Contents  • Related specifications  • Software requirements  • Data exchange requirements  • Master dictionaries/reports  • Preconstruction meeting  • Qualifications of scheduler  • Required submittal contents  • Owner mandated milestone treatment  • Float ownership  • Prohibitions of manipulation  • Planning units/ calendar requirements  • CPM Network requirements  • Duration definitions and restrictions  • Initial schedule submission  • Full detailed project schedule (baseline) submission  • Schedule updates  • Delays and time extensions  • Early completion schedules  • Final as-built submittal  • Short interim schedules  • Cost and resource loading narrative requirements  3. Team Players  • Organizational Chart (OBS)  • Who are Schedule Users?  o Who has Input  o Who Updates  o Who Checks for Accuracy  o Who Reviews  o Who approves  • Identify Responsibility Assignment Matrix (RAM or RACI)  4. Software Identification  • Specific software  o Required minimum and versions allowed  • Enterprise specific issues  o Users identified  o Schedules used for import or data source  o Levels of access  o Validation process  o For master schedules, establish data dates  5. Work Product  • What the Schedule can be used for (purpose)  • Reports Generated from the Schedule  o Who receives reports  o List of reports  o Samples of reports  • Glossary/Lexicon of ambiguous terms and three letter acronyms (T.L.A.s)  6. Schedule Outline  • Key Activities being tracked  • Client Milestones  • Long Lead Items  • WBS Structure  • Other Contracts on Project  7. Work Package Development  • By Contract.  • As assigned by Client  8. Level of Detail  • Determine approach:  o Bottom-up (starting with detailed activities)  o Top-down (starting with summary schedule)  o Both (prepare Top-down, then Bottom-up)  • Identify frequency of updates  • Establish smallest activity duration range  9. Codes Dictionary  • For tracking and monitoring work:  o Work Phase  o Structure  o Area  o Floor or Station  o Location.  • For Project Management  o Responsibility  o Work Shifts  o Costs  o Resource  o Specification  o Change management  10. Calendars  • Establish number needed  • Define calendars and application 11. Costs & Resources  • Estimate & correlation to cost loading  • Bill of Quantities & use in resources  • Resource Crew descriptions  • Equipment descriptions  • How actual production will be monitored  • Earned Value Management System  12. Narrative Basis & Assumptions  • Procedure Used to create the Schedule  • Definitions/lexicon  Example of Lexicon:  General Notes Regarding this Report:  • “Program,” “Programme,” and “Baseline CPM,” and “Schedule” all  have the same definition and are used interchangeably.  • “Snagging” and “Punch-out” have the same definition and are  used interchangeably.  • “Fixed” and “Rough-in” have roughly the same definition. For  clarification purposes, “Fixed” has been used in this Program.  • “Conventional concrete” is defined as post-tension poured-inplace  concrete.  • “Wild Air” is defined as a stage in construction, for which the  building is closed in by perimeter walls and ventilation has  started. (Ventilation only, not complete environmental controls or  functioning air conditioning.) This term is used in lieu of  “environmental controls,” or “drying –in”.  • “Raft” construction consists of the foundation including but not  limited to piles, grade beams, footers, and slab-on-grade.  • Description of sequence of work per structure  13. Risks & Constructability (use of BP’s RAT and identify, assess, respond, control risk processes)  • Brainstorming of issues  o Known problems (threats)  o Provisional Items  o Predicted Problems  o Lessons Learned  o Outside influences  o Site condition concerns  o Opportunities  • Develop Risk Management Plan  o Initial process during baseline schedule development  o Process for use during updates  14. Weather planning  • Expected adverse weather  • Identify source or specification requirement  • Identify methodology  • Identify accounting method for actual weather  15. Time Contingencies  • Amounts  • Specific trade (from risk management plan)  • Specific contractor contingency  • How carried  • Use historical data for reference  16. Establish Update process  • Frequency  • Data request and transmission  • Validation  • Process flowchart  17. Change Management process  • Notification requirements  • Methodology allowed  • Process flowchart  18. Recovery process  • Identify what logic changes are acceptable without formal approval  • Identify what constitutes a Revision requiring approval  • Provide process description or flow chart  19. Dispute resolution process  • Review program for claims avoidance  o Reinforce planning for claims avoidance  o Identify specific program for claims avoidance during schedule updates and change management  • Identify steps if change management process fails or stalls  • Follow specifications  • Provide time frames for stages in process  • Provide process description or flow chart
Last Edit: 13 years ago by . Reason: (NULL)
OFFLINE
Joined On:
30 Sep 2017

Re: How to build a quality, good schedule and/or plan

17 November 2011 3:36
@ ALL: Great joint effort. Keep it up! 
OFFLINE

Re: How to build a quality, good schedule and/or plan

17 November 2011 3:43
Here are some rules to minimise the chances of your plan to get failed and ensure project completes before or on time. Ø             Most importantly, Project Planning & Scheduling must involve decisions concerning : ·         the overall strategy of how the work process is to be broken down for control; ·         how the control is to be managed; ·         what methods are to be used for design, procurement & construction; ·         the strategy for subcontracting and procurement; ·         the interface between the various participants; ·         the zones of operation and their interface; ·         maximising efficiency of the project strategy with respect to cost and time; ·         risk and opportunity management. Ø             In the process of converting the plan into a schedule  the scheduler should determine: ·         the duration of the activities; ·         the party who will perform the activities; ·         the resources to be applied to the activities; and ·         the method of sequencing of one, or more activities in relation to other activities. Ø             Depending upon the density of the schedule, the purpose for which it is to be used and the information available, an activity duration must be derived from following only. Any assumptions must be documented in case needs to be validated in future. ·         experience ·         industry standards ·         benchmarking ·         comparison with other projects ·         calculation from resources ·         specification. Ø             The schedule must illustrate a realistic and practical project plan showing how the project is intended to be, in a form that is sufficiently accurate for its identified density. Ø             Schedule must be capable of identifying the following: ·         the longest path to completion; ·         the longest path to intermediate key dates, or sectional completion dates; ·         logic and activities, which are critical from those, which are not critical to one, or more completion dates; ·         total float on each path; ·         free float on each activity, on each path; Ø             The strategy for schedule review must take account of the development of the schedule as better information becomes available and, as the project proceeds, the increasing density of the schedule as it develops from initiation through the work on site to commissioning the completed project. Ø             When change is imposed, scheduler must be able to identify it contemporaneously, the effect of delaying and disrupting causal events on the planned sequence and to advise team members on the likely effect of possible recovery strategies. Ø             Risk is inevitable part of any program however if dealt well, can be brought under control. Contingency period to deal with risks should be designed to be identified separately for both the employers and the contractors risks and for those risks which are related to: ·         an activity, or chain of activities ·         a contractor, subcontractor, supplier, or other resource ·         an access, or egress date, or date of possession, or relinquishment of possession ·         the works, any defined section, and any part of the works. Ø             For Schedule reporting , it is impracticable to use the whole of the schedule at any one time in its detail. For effective reporting it should be summarised to different degrees of summarisation for differing purposes. Most project scheduling software packages facilitate this hierarchical structuring by virtue of a summarisation, or roll-up facility. Some basic tips: Do not use Mandatory Constrained dates. If a constraint has been used, then “Start on or After” can be opted. Keep use constraints as minimal as possible. Adopt Finish to Start logic as much as possible. Avoid SF links completely. No “Dangles” at all in schedule. LOE tasks could be an exception here. Avoid use of lags, especially long duration lags Keep Level 3 activities to similar levels of detail whenever possible Roll-ups from Level 3 to Level 2 must be “many to one” with no splitting of level 3 activities into individual level 2’s Status activities only after confirming its reliability & source Make your activity ID’s intelligent to identify where it belongs to. WBS development is must before the creation of schedule Avoid changing RD just to keep the activity out of critical path Identify Key Events and Drop Dead Times before developing the plan Schedules needs not to be way too detailed. Be realistic irrespective of pressure from Client, Project Managers and Engineering/Construction leads. Avoid “tweaking” of the logic to “make it fit.” Activities must be linear and sequential (Finish-to-Start), instead of being overlapped, i.e., successor starts before the predecessor – a version of “fast-tracking” at the molecular level. Planning procedure should encompass familiarisation, outline plan, strategic plan and detailed plan along with planning method statement Do not deceive (to mislead by a false appearance or statement). Don’t mislead the schedule by false appearance Get buy-in from the responsible owners of the plan. In absence of this, plan is no more than a worthless piece of paper. Ensure the calendars are set before developing the plan to includes the holidays and working hours restrictions, if any. Activity codes should identify the various attributes of the schedule as fields, the values of which will facilitate organisational changes, and facilitate filtering of important parts of the schedule. Schedule review must check for buildability, content, integrity, constraints, open end tasks, long lags, negative lags, ladders and critical paths to name a few. Summary: Don’t twist the plan, contort the plan, reduce the plan, expand the plan, modify the plan, distort the plan, adjust the plan, change the plan.. Instead, follow the plan..
  • Page:
  • 1