Schedule Development


The Project Master Schedule is developed by defining and sequencing tasks/milestones, estimating task/activity durations, documenting constraints and, and considering resources. The PMS will contain baseline schedule data, as well as, current schedule status and projections.

Schedule development “best practices” help to ensure valid schedule data, that tasks and milestones, realistic task/activity durations, logical inter-dependencies have been incorporated, and only valid constraints have been assigned. The time-phased sequence of project tasks and milestones is called the Logic Network. This process is called “Critical Path Method” (CPM) scheduling and is considered a standard industry “best practice”. Logic Networks provide a basis for time-phasing of all project tasks and milestones. This time-phasing is critical in the implementation of Earned Value Management (EVM).

Table of Contents

Data Structuring

A key consideration in schedule structure is making the data understandable and easy to follow and use. Keep in mind that if the data doesn’t make sense it won’t be used. Many times it is the simple things we do that make a big difference. For example, making sure that task and milestone descriptions are complete enough to understand what work is being scheduled. This applies to all tasks, not just summary level tasks. Additionally, a less obvious, but just as important reason for clear task descriptions is that they enhance critical path analysis. Identifying and conducting effective critical path analysis entails filtering for only those specific tasks/milestones that are driving the project end date, and ordering them chronologically in an understandable format without the associated summary tasks. A lack of clear understanding of the effort involved in each task makes analysis of the critical path very difficult and time consuming.

Another simple approach recommended for structuring a schedule is to input the task and milestone data in the order and groupings that make sense. This is not referring to network logic, but just using some organisational forethought when initially entering the data. Doing this reflects a meaningful flow of work, and makes sense even without considering formal logic relationships.

It is also recommended to structure schedule data using a predominantly task-oriented (activities with durations) approach, with milestones included only to reflect major events, key interface points, decision points, and the like. Schedule structure that is task-oriented lends itself to a more meaningful approach to monitoring task progress. Each activity is in the schedule with a duration that is monitored and updated to show its progress leading to completion. When tasks are progressed correctly they provide not only a clearer picture of task status, but also an early warning of completion dates that are in jeopardy. If this is the case, the schedule may require new forecast starts and/or completion dates for those specific tasks that are in jeopardy. When only milestones only are used to reflect task starts/finishes, it is very difficult to show how the project is progressing toward meeting the milestones. Many times milestones are slipped at the last minute because the actual progress toward milestone completion is not reflected in a clear and obvious manner, and unfortunately, not adequately addressed until it is too late to recover.

Task/Activity Definition

Task definition begins with the PBS. Extending and detailing the PBS down to discrete and measurable tasks is the beginning of the project schedule. Starting with the approved PBS will not only help ensure that the total scope of work is included in the schedule, but also will ensure consistency in the correlation between cost and schedule data. The task/activity level of detail should be sufficient to allow for a meaningful measure of progress and the practical establishment of defined finish-to-start network logic relationships.

Task descriptions should be concise yet complete. The task description should be complete enough to stand on its own, but concise enough to facilitate ease of use.

A task nomenclature convention or methodology should be established at the beginning of the project and adhered to throughout the project life.

Schedule Detail

The phase and maturity of a project will determine the amount of detail that can be built into a schedule. In general terms, the earlier in the definition process, the less detail is available.

You may need several view of a schedule, at various level of detail, depending on the needs of the stakeholders The level of detail contained in the schedule should also be a reflection of the intended use of the schedule. Management or presentation schedules may contain less detail than schedules used by the project team. Remember, the greater the level of detail in a schedule, the greater the level of fidelity the schedule has. It should also be understood that more detail would normally be required for tasks that are closer to the critical path or areas of high risk.

The level of detail in a schedule should be sufficient to

(a) accommodate a clearly defined logical sequence of activities,

(b) describe a step-by-step process for accomplishing all phases of work leading to product deliverables, and

(c) accommodate the collection of actual time and cost charges at the appropriate level.

The level of detail in the schedule should reflect discrete, measurable tasks that relate to PBS elements. Every PBS element should have at least one schedule task. Plan the entire project, but the level of detail may vary based on the project phase. Try to break down the sequence of events so that when one task/activity finishes, another starts. If the schedule is developed using this approach, the effort of logically connecting the tasks/activities will be much easier. Tasks should be detailed enough so that interface points can be clearly identified. These interface points can be where a task is passed from one group to another or a task progresses from one phase to another.

Always keep in mind as you are developing the schedule that updating will be required for each schedule task. Each task should be clearly and easily identifiable for updating purposes.

Milestones that are important to the program or project should be created. There are many other important interface points, phase conclusions, and “hand-offs” where milestones would be appropriate. Milestones should be tied to or represent a specific product or event and should have clear, objective (quantifiable) criteria for measuring accomplishment. This should be binary; done or not done.

Another factor to consider in determining the level of detail for a schedule is the impact this will have if using Earned Value Management (EVM). The level of detail used must lend itself to meaningful cost/schedule integration. EVM performance measurement baseline (PMB) consists of a schedule plan that is consistent with the cost plan. The level of schedule detail might determine the type of EVM measuring technique (e.g., 0-100, 50-50, weighted milestones, percent complete, level-of-effort, etc.) that will be assigned in each EVM work package.


Task Coding

Coding of activities can aid in organizing, displaying and reporting schedule information. It can also facilitate consistent vertical schedule integration among master, intermediate and detailed schedules within the context of the overall PMS.

The number of codes needed for a project will vary widely, depending on project size, technology, complexity, entities involved, phase, and so on. Before deciding whether or not to use a particular code it is worth asking:

What would this be used for?Who will use it (stakeholders)?Is there another (i.e. easier) way to get the desired results?

It is good practice to document project coding especially for programmes.

Typical codes are:

1 The Responsibility code
A commonly used code. This type of code can be used in a number of ways, such as a reference to a person, a team, or any other group. This is NOT the same as the OBS, but rather a more specific identifier. The code can be useful for sorting and grouping of data into distinct work groups. The result may then be used to collect status, plan resources, or to communicate a group’s work plans.

2 Phase code.
This code is usually as a logical grouping of work that flows along the project time line more or less sequentially. For example, one such definition may result in phases such as Design, Build, and Testing. It is often used to organize data to facilitate interface-planning efforts and produce summary level reports.

Once a particular code is defined for use in a project, it is recommended that the code value be used consistently for all related project data. For example, if the resource abbreviation “E” for Engineers has been established, this resource abbreviation should be used in all places where a resource abbreviation for Engineers is required. Consistency is the key to a successful data structure and coding scheme.

Other commonly used codes include;

3 task/activity ID
4 Priority
5 Control Accounts (or Cost Accounts)
6 Completion Flag
7 System – Project Specific
8 Sub System – Project Specific

Rolling Wave Planning

The rolling wave concept is a method of scheduling that involves the use of detailed and summary tasks.

When using the rolling wave method, near-term tasks are planned to a lower, discrete level detail. Near-term typically implies 3 months to 6 months from the current date (the planning Horizon). Tasks that are scheduled to occur farther into the future may be planned at a more summary level of detail, but still included in the schedule. These summary tasks, while reflecting less detail, should still provide enough definition to future work to allow for identification and tracking of the project critical path that flows to project completion. On a monthly basis, as future summary level tasks come into the planning Horizon, they should be planned to a greater level of detail and incorporated into the PMS. It is important to note that it should not used as an excuse for not reflecting the most meaningful level of detail anywhere in the schedule if the information is already known. It cannot be stressed enough that planning and scheduling at a discrete level of detail as early as possible will identify and mitigate many project problems, conflicts, and risks.

Be aware of the inherent risks. It is quite possible that future detailed planning will reveal situations that, if known earlier in the project, could have resulted in more efficient and less costly work plans. It is a widely accepted that advanced planning in the early stages of a project yield significant cost and time benefits when compared to the original cost and time investment.

Task Relationships

Logic relationships are critical to accurately modeling a project’s planned activities in the PMS. There are four relationship (interdependency) types:The finish-to-start relationship - By definition, a preceding activity must finish before a successor activity can start. It is recommended that this relationship be used as often as possible when establishing schedule logic. This relationship provides for the most accurate calculation of total floatThe start-to-start relationship - The preceding activity must start before the successor can start. This relationship is used when two activities need to begin at relatively the same time. In most cases this relationship will be used with a lag value.The finish-to-finish relationship - The predecessor must finish before the successor can finish. This is another relationship that is often coupled with a lag value. This relationship is used when an activity needs to finish and provide something to another activity so that it too can finish. The start-to-finish relationship - The preceding activity must start before the successor can finish. This relationship is almost never used. It can create difficulty in total float calculations with no clear critical path resulting. The use of this relationship is strongly discouraged.

It is important to only assign logical relationships where they really exist. Avoid false dependencies as this can produce a flase critical path.

Lag and Lead Use

Lag time is the period of time applied to a relationship between two tasks that delays the start. For example, a task logically tied to another task with a finish-to-start relationship and a 5-day lag will result in the successor task’s start being delayed until 5 days after the completion of the predecessor.

Lead time is the period of time applied to a relationship between two tasks that accelerates the start. The amount of lead time (acceleration time) is assigned as a negative value. For example, a task logically tied to another task with a finish-to-start relationship and a negative 5-day lead will result in the successor task’s start beginning 5 days prior to the completion of the predecessor.

Lead and lag times should only be used when these values represent real situations of needed acceleration or delay time between tasks. Use of lead and lag creates a maintenance issue should the lead or lag time change. Lead and lag times are not very visible and often difficult to discern when analyzing a schedule. They may also corrupt float/slack calculations and incorrectly affect the critical path. It is recommended to avoid lead and lag and instead use a task, appropriately labeled, to represent the lead or lag time and to describe the reason for the lag or lead. This gives visibility and a more easily maintainable schedule


A constraint is a fixed date assigned to a task to control when it starts or finishes. Caution should be exercised when using constraints because they are a significant factor in how float (slack) is calculated throughout the project schedule. Common constraint types that can be imposed on an activity include, but are not limited to, the following:

^These types of constraints act as completion points in the schedule, from which the total float value is calculated. Ideally, minimal use of constraints, other than As Soon As Possible, is strongly encouraged.

While constraint use is sometimes necessary, it should be used only when required to accurately reflect the plan. When used, careful consideration should be given to which constraint type to use. The type of constraint will dictate the impact on float (slack) calculations for the task in question and other tasks logically connected to the task in question.

Task Durations

Prior to estimating durations, a determination should be made as to the unit of measurement and level of accuracy required. For a short term, intense effort, activities may be required to be measured in hours. For a long duration plan, it may be desirable to round activities in the first year to the nearest day, and in subsequent years to the nearest week, refining the estimates, as the activity gets closer. It is usually desirable to have all time units alike in a schedule. For example, all durations may be entered in “days”, even if a fraction of a day is a valid duration for a given task.

It is also important to establish whether activities will be measured by elapsed time or by number of working days, and to be consistent throughout the schedule. Alternate calendars can be established to allow activities with different work schedules to be more accurately planned.

Duration is the length of calendar time, as defined by the project, a task is expected to take to complete. Some common methods and sources for deriving or enhancing duration estimates include the following: established standardsexpert experience and judgment, analogous comparisons using historical or related data, parametric analysis, team brainstorming extrapolations from known data and trends (e.g.; 3-point expected value)

Always be on the look out for valid sources and processes to assist in deriving the most accurate task durations possible for schedule development.

Durations should be revisited periodically as work progresses, and as new information becomes available. You will know more about the tasks at that point. Durations should not be padded in order to keep a hidden contingency, reduced to be optimistic, or arbitrarily cut by management.

If available, make use of historical schedules.

When interviewing to determine estimates from people, always get the optimistic duration, the pessimistic duration, and the most likely duration based on the probability of associated risks. Calculating an expected value from these three estimates will typically provide a more realistic duration estimate to use in the schedule.

Schedule Calendars

Resource calendars specify valid time units that a resource may be available to do work. Task calendars specify valid time units that a task or multiple tasks may be worked. Both resource and task/activity calendars should be used where appropriate and be a key consideration when estimating task durations.

Resource Impacts

Resources can be classified as belonging to three categories: workforce, equipment, and consumable. In estimating an activity’s duration, it helps to know the skill level of the resources that will be assigned. An inexperienced technician or crew, for example, may take longer to perform the task than an experienced technician or crew.

Duration Risks

Project Risks and schedule risks should always be addressed when task duration estimates are made and when the schedule is analyzed. Project risks that impact the schedule include design issues, fluctuating resources, resource experience, and changes in budget. Schedule risks include inaccurate estimates from overestimating or underestimating durations, changing or unaddressed scope, task definition changes, and late deliveries.

As each task’s duration is estimated, an optimistic and pessimistic duration value for each task should also be recorded. The optimistic value should be the least amount of time required to complete the task or the minimum duration the owner of the task will permit. The pessimistic value should be the greatest amount of time required to complete the task or the maximum duration the owner of the task will permit.

This is also an opportune time to assess the likelihood of a task finishing somewhere between the optimistic and pessimistic duration values. If this is identified, a probability distribution function (PDF) can be assigned to each task that will model this likelihood during probabilistic risk assessment simulations

Allocating Resources

When resources are assigned to tasks, this is referred to as resource loading. Resource loading is the process of assigning specific people, materials, etc. to a task or tasks requiring that expertise or that particular material.

Resource loading can provide valuable information regarding over or under allocations in a schedule. This information can alert the project manager if a task cannot be completed in the time scheduled due to a resource shortage. Note also that adding resources rarely shortens the task duration, overtime is usually the only way to do more in a given period.

Resource Leveling

Resource leveling is the process of moving schedule tasks without violating network logic or constraints in order to achieve a more consistent level of resources throughout the schedule duration. Analysis through resource leveling is a process that can only be accomplished when a schedule is resource loaded. Additionally, for the process to provide credible data, the schedule must be structured as an end-to-end logic network with all interdependencies identified. It should be noted that the resulting schedule data should be reviewed carefully, and not just taken at face value, to ensure credibility for project implementation.

Resource loading and leveling is the recommended method to accurately validate whether the scheduled project completion is achievable with the allotted resources available. To baseline a project schedule without first resource loading and conducting leveling analysis is to assume a significant risk in achieving project completion within budget and on schedule.

Resource Rates

Rates for each resource are determined and applied to calculate the cost of labor, material, or other resources assigned to each task. This is useful in facilitating the evaluation of the cost impact of a schedule change. This is also necessary to facilitate Earned Value Management (EVM) for the project.

Schedule Reserve

Schedule reserve based on risks and historical norms must be clearly identifiable within the PMS. Schedule reserve is owned and controlled by the Program/Project Manager and it is determined by:

a) expert judgment,

b) rules of thumb,

c) % of overall project (or activity) duration,

d) calculated by expected value of risk impacts, or

e) through insight gained from a probabilistic schedule risk assessment.

Schedule Slack, which is a calculated value based on network logic, should not be considered as schedule reserve.

Schedule reserve is used for future situations that are impossible to predict. It is a quantity of time above the planned duration estimate specifically identified in the schedule as “Schedule Reserve” and is intended to reduce the impact of missing schedule objectives. The reserve is inserted into the PMS at strategic locations.

For prince 2, schedule reserve is a combination of tolerance and contingency.

For critical chain method, schedule reserve is project and feed buffers.

The PMS Baseline

Prior to PMS baselining, it is essential to validate that SOW, PBS, and Schedule all agree. The SOW document should contain a narrative description of the entire scope of work for the program/project effort in a structured, product-oriented fashion. The PBS should also reflect the entire scope of work for the program/project in a structured and even more defined product-oriented fashion. Each of the PBS elements should be reflected in the project schedule. Therefore, each scheduled task/activity should have a related PBS element.

25 January 2009 (11)