Project Schedule Development Guidelines

Project Schedule Development Guidelines
Project Schedule Development
Guidelines
v1.0
Author: Ashok Kumar LalSingh
01 Nov 2015
Copyright Notice
Document Template Reference No: 1-1
Copyright © Taajeer Co., KSA
Website: www.taajeer.com,
Doc Ref No: 1-12
The document “Project Schedule Development Guidelines” has been authored by Ashok Kumar LalSingh, Taajeer
Co., KSA.
Taajeer Co. reserves all rights to modify this document and permit its uses. Use of this document for the purpose
other than personal reference is not permitted without the explicit authorization from Taajeer Co. Taajeer Co will
not be responsible for financial or any other losses arising due to the unauthorized use of this document.
The trademarks or registered trademarks referred in this document are all duly acknowledged hereby.

Project Schedule Development Guidelines v1.0
Index
1 Introduction..............................................................................................................................................4
2 Inputs to Schedule development.............................................................................................................4
2.1 Project Management Methodology...................................................................................................4
2.2 PBS (Product Breakdown Structure), WBS and Network diagrams...................................................4
2.3 Project Network Diagram...................................................................................................................5
2.4 WBS (Work Breakdown Structure) and Work Packages....................................................................6
2.5 Project Schedule Templates ..............................................................................................................6
2.6 Planning Levels...................................................................................................................................7
2.7 Schedule Ownership and responsibilities..........................................................................................7
3 Steps for developing a Project Schedule..................................................................................................7
3.1 Quality Assurance, Administration, Issues and Risks.........................................................................7
3.2 Dependencies.....................................................................................................................................8
4 Steps to create MS Project Schedule.......................................................................................................9
4.1 Step-1: Ensure correct MS Project settings........................................................................................9
4.2 Step-2: Enter Project Information......................................................................................................9
4.3 Step-3: Create Schedule Structure.....................................................................................................9
4.4 Step-4: Enter Tasks and task details...................................................................................................9
4.5 Step-5: Enter tasks relationship.........................................................................................................9
4.6 Step-6: Assign Resources and allocation Units................................................................................10
4.7 Step-7: Do resource levelling...........................................................................................................10
4.8 Step-8: Enter Task Codes and Task Leader Resource names...........................................................10
4.9 Step-9: Test automation tools if any................................................................................................10
4.10 Step-10: Review and update..........................................................................................................10
4.11 Step-11: Baselines..........................................................................................................................10
4.12 Step-12: Schedule Approval...........................................................................................................10
5 Task Details.............................................................................................................................................10
5.1 Task Duration = Days.......................................................................................................................10
5.2 Task Work = Hours...........................................................................................................................11
5.3 Task type = Fixed work or Fixed units..............................................................................................11
5.4 Constraints Type = As Early as possible............................................................................................11
5.5 Task Description size........................................................................................................................11
5.6 Task Notes........................................................................................................................................11
5.7 Task Relationship..............................................................................................................................11
6 Resources...............................................................................................................................................11
6.1 Names...............................................................................................................................................11
6.2 Lead Resource..................................................................................................................................11
6.3 Availability: ......................................................................................................................................12
6.4 Leveling: ...........................................................................................................................................12
6.5 Work Completion: ...........................................................................................................................12
6.6 Actual Work: ....................................................................................................................................12
6.7 Inserting Tasks after baseline: .........................................................................................................12
6.8 Commitments: .................................................................................................................................12
6.9 Absence Plans: .................................................................................................................................12
Doc Ref No: 1-12
Page 2 of 19

6.10 Replacements: ...............................................................................................................................12
7 Calendar settings: ..................................................................................................................................12
8 Dependencies between tasks: ...............................................................................................................12
8.1 nFS (Finish to Start. Example 6FS): ..................................................................................................12
8.2 nSS (Start to Start. Example 10SS):..................................................................................................12
8.3 nFF (Finish to Finish. Example 18FF): ..............................................................................................13
8.4 nSF (Start to Finish. Example 29SF): ................................................................................................13
9 Baselines: ...............................................................................................................................................13
10 Approval: .............................................................................................................................................13
11 Fields reserved for use: .......................................................................................................................13
12 Addressing Security Issues...................................................................................................................14
13 Schedules Inventory.............................................................................................................................14
14 Definitions and Terms used in Schedule Development.......................................................................14
15 Appendix-A...........................................................................................................................................18
16 References ...........................................................................................................................................18
17 Glossaries .............................................................................................................................................18
18 Document Control................................................................................................................................19
Doc Ref No: 1-12
Page 3 of 19

1 Introduction
Project Schedule is a very important, essential and critical part of project planning and control. Though not
correct, project schedule may also be referred as project plan. Organizations create schedule guidelines for
promoting good planning practices. The purpose of this document is to highlight some of these practices. As
planning requirements may vary from organization to organization, scheduling practices may also vary from
organization to organization.
The guidelines described in this document may not be applicable uniformly to all types of projects. For most
guidelines except few that are mandatory, you should make your considered decision for your situation.
To assist you with definitions and terms used in planning and scheduling a list of definitions and terms has
been provided at the end of this document.
2 Inputs to Schedule development
To develop a good project schedule you use several inputs. Following are some of these inputs. In special
situations you may need additional inputs.
2.1 Project Management Methodology
Schedule development guidelines are normally part of Project Management methodology used by an
organization. Most organizations have Project Management methodologies tailored to specific
requirements. Schedule development is assisted to a large extent if your organization uses a Project
Management Methodology, particularly for the following:
• Identification of deliverables required to execute the project management and delivery processes. Many
of these deliverables are not part of customer deliverables. Utility of these deliverables is within the life
span of the project.
• Default project network diagram is easily constructed based on the Project Management Methodology.
This helps in setting high level dependencies in a project schedule.
• High level default WBS is readily available from Project Management Methodology.
2.2 PBS (Product Breakdown Structure), WBS and Network diagrams
For large projects creation of Product Breakdown Structure (PBS) and Work Breakdown Structure (WBS)
and project execution Network Diagram are part of best practices and prerequisite for creating a project
schedule. However, use of PBS, WBS and Network Diagram are not mandatory for schedule development
for all projects.
PBS creation should preferably be based on project deliverables which are derived from project scope and /
or project objectives (the primary deliverables) and the project management and delivery processes (the
secondary deliverables). PBS development is covered in “Guidelines for developing Product Breakdown
Structure” document.
Fig 1 shows a sample Product Breakdown Structure of a Mountain Bike.
Doc Ref No: 1-12
Page 4 of 19

Fig. 2.2 Product Breakdown Structure
2.3 Project Network Diagram
Project Network diagram is a high level view of work inter dependencies and time phased execution of
work. CPM (the Critical Path Method and PERT (the Project Evaluation and Review Technique) are two
methods for describing and analyzing project network diagrams. Discussion on CPM and PERT is out of
scope of this document.
Project Network Diagram is frequently used to plan parallel execution paths along with inter path
dependencies. Parallel execution is a scheduling strategy to meet certain goals such as technical
requirements, time constraints, independencies of tasks/teams and other administrative and financial
constraints.
Following are few examples of variations in high level Project Network Diagrams.
Doc Ref No: 1-12
Page 5 of 19

2.4 WBS (Work Breakdown Structure) and Work Packages
WBS represents the progressive elaboration of work required to produce all of the project deliverables. The
lowest in the hierarchy of WBS are Work Packages. The content of WBS is ultimately reorganized in Work
Packages. A Work package may include various types of tasks for more than one deliverable. Often work
packages cluster similar type of work and optimize resource utilization. Ensure that WBS Work Packages
are correctly associated along with project network paths. WBS development has been explained in the
“Guidelines for creating Work Break Down Structure” document.
For further details of WBS, please follow this link……
2.5 Project Schedule Templates
Project Schedule development can be expedited through various ways such as using predefined templates
based on best practices and then tailoring the selected template to suit the project needs. Most of the
Scheduling tools have provision for using scheduling templates. You should tailor the selected template to
reflect project's network diagram structure and associated deliverables / WBS work packages.
If a project schedule template is not used, you can create Project schedule structure based on Network
Diagram and associated deliverables (PBS) and work packages of WBS. This schedule structure should
also adhere to convention of project phases, stages, work grouping and deliverables.
Doc Ref No: 1-12
Page 6 of 19

2.6 Planning Levels
Project Schedule may have different levels of details. You must define these here. It is also useful to define
hierarchy of planning levels. You should define the frequency at which these plans be updated and status
reporting is processed. Different levels of plan may be based on different inputs, may serve different
purposes and may be maintained differently. Planning levels does not necessarily represent progressive
elaboration of schedule development along the project life cycle. Planning levels depends upon the project
management structure in your organization. For example an organization may have level 1 project schedule
at programme level, level 2 project schedule at release level, level 3 project schedule at discipline level.
2.7 Schedule Ownership and responsibilities
Schedule development involves several roles such schedule owner, project planner, project leads, planning
manager, release manager, programme manager and PMO head whose responsibilities should be defined
in Schedule development plan.
3 Steps for developing a Project Schedule
The steps described herein are for schedule development using MS Project. However the concepts are valid
for other tools also.
Following is one of the several accepted step by step methods for developing a project schedule.
• Use Network Diagram to identify parallel execution paths, major dependencies and major slack periods.
• Associate WBS Work Packages along with network paths.
• Create Project schedule based on Network Diagram and associated work packages of WBS.
Dependencies at this stage are as per network diagram.
• Enter detailed tasks for work packages. Do not forget to include review and approval of document
deliverables. Also include all administrative tasks.
• Enter milestones and their dependencies (internal to project). Milestones indicate start or end of major
deliverables, service request or compliance events or dependencies on other projects.
• Enter milestones for dependencies on other projects. All tasks executed out of the project schedule,
should be included as milestones with external dependencies on some task in schedule of other projects.
• Refine dependencies. Ensure that all tasks have predecessors.
• Assign tasks to Group Leaders.
• Get tasks work estimation done (by group leaders).
• Enter duration for detailed tasks.
• Assign resources and work hours required by resource to tasks. Identify maximum locatable time in
percent for each resource before assigning resources
• Review Draft Schedule for estimates, dependencies, and assigned resources including lead.
• Make adjustments in schedule structure for EVA purpose
• Review resource loading and do resource leveling
• Get schedule approved by required stakeholders
• Baseline schedule. Before base lining, make a backup copy of schedule.
3.1 Quality Assurance, Administration, Issues and Risks
There are variations in including tasks require for quality assurance, project administration, managing issues
and risks. Ensure that administrative, issues and risks tasks are included in the project schedule at the end in
a group. Do not scatter these tasks.
Include Quality Assurance tasks such as walkthrough / review and approval of deliverables, compliance
certificates, defects tracking, project audits etc at appropriate places in schedule. The following is an example
list of tasks that may be included for quality assurance of controlled documents.
• Document registered (milestone)
• Creating Draft document (task)
• Document sent to first level reviewers or walkthroughs (milestone)
• Review and rework document (task)
• Document sent to mandatory reviewers if required (milestone)
Doc Ref No: 1-12
Page 7 of 19

• Review and rework document (task)
• Document sent to approver (milestone)
• Rework and approve document (task)
• Document approved (milestone) – final stage for internal documents
• Document issued to customer or sponsor for approval (task)
• Document signed off by customer or sponsor (milestone) – final stage for external documents
Enter all project issues and manage them as normal tasks. Issues start / finish dependencies may be driven
by other project tasks. An issue may have external dependencies also. Finish of an issue may also have
impact on start or finish of other tasks. Assign resources to resolve issues as it's done for a normal project
task. When an issue is resolved, mark it complete by updating % work complete to 100%.
Enter all project risks and track them as special events with start and finish dates represented by the duration
when the event may happen i.e. the probability of occurrence of the event before start date or after finish date
is zero. Risk occurrence period may be driven by other project tasks and external events. A Risk event may
happen any time after start or before finish date. Risks are marked as finished as soon as they happen or
finish date is reached. At Risk's occurrence % work complete is updated to 100%.
Risk mitigation plan may be documented in the Task Note field or in a separate document linked to Risk.
Assignment resources to mitigate the risk are also done in normal ways. Risk mitigation may require one or
more tasks that can also be managed as normal tasks. For example - creation of mitigation plan may be
treated as a task. Execution of mitigation plan may be treated another tasks etc.
Some organizations use separate tools to managing Issues and Risks. Tools help in escalating these tasks.
You may be tempted not to include these tasks in project schedule. Avoid this temptation.
3.2 Dependencies
3.2.1 External dependencies
External dependencies should be shown as milestones. Also tasks executed out of project schedule, should
be included as milestones with external dependencies.
External dependencies are identified when start or finish of a deliverable, service request or compliance is
dependent on other projects or functions (departments) or an external organization.
A milestone showing external dependency is linked within project schedule through a lag or lead period with
respect to another task or milestone. In case, there is no such link, milestone date is updated manually.
3.2.2 Dependencies Correctness
Ensure that all tasks have correct dependencies i.e. predecessors or successors or both. Correctness of
Critical Path largely depends upon correctness of dependencies.
Refine dependencies such as preparation and review of documents finishes together I.e. use Finish - to
Finish relationship in these cases, if you can make start and finish dates depending upon other tasks.
3.2.3 Lead Resources
Identify Task Leaders or lead resources and get tasks estimation done through them. You can also use
subject matter expert to estimate tasks. Wherever possible, get tasks estimates endorsed by actual
resources.
When more then one person work on the same task, its easier to collect task status from one person called
as Task leader. Normally Task leader is the first resource assigned to task. Other resources are assigned
with task leader's involvement in schedule development.
Do not load resources beyond the availability unless it is committed by resources. Resources not available
for full time should be loaded appropriately less than 100%.
To ensure availability of resources, use appropriate tools for resource load leveling.
Doc Ref No: 1-12
Page 8 of 19

4 Steps to create MS Project Schedule
4.1 Step-1: Ensure correct MS Project settings
The first step in creating a new project schedule is to ensure that MS Project options settings are correct. In
case you have used a project schedule template, check all options settings, project information and tasks
settings and ensure that all settings adhere to guidelines mentioned herein.
MS Project's Options settings include Calendar, schedule, view, edit etc. Also set Text style using Format
menu item. Some values of setting are given in task details and calendar settings herein this sheet. If
schedule is generated from this tool, option settings are done automatically. However, you should check
these automatically done setting before entering tasks in MS Project.
Besides Options settings you may specify the MS Projects Global Template settings for custom fields,
views, reports, forms, tables, filters, calendars, maps and groups if needed. You should also mention file
naming conventions and guidelines compliance checks. Some of these are covered in more details in the
following sections.
The easiest way to enforce the correct settings is to use schedule templates and VBA macro to change
settings if template is not used. However, the schedule standard must describe these settings so that it can
be used as reference for templates development or VBA macro development.
4.2 Step-2: Enter Project Information
After ensuring correct options setting, the next thing is to enter project information such as Project Name,
Start date and Forward Scheduling etc. You should not enter tasks before entering this information.
In case you have used a project template, review project information and make corrections.
4.3 Step-3: Create Schedule Structure
Create schedule structure similar to the following.
1st grouping level -> Project Phase or stage
2nd grouping level -> Grouping within the phase
3rd grouping level -> Deliverables
4rth grouping level -> Grouping within deliverable
5th grouping level -> Detailed Tasks
Avoid structure indenting levels beyond 5. If you have used a project template, ensure it adheres to
schedule structure mentioned herein.
4.4 Step-4: Enter Tasks and task details
For a new Task, enter details such as task description, duration and Notes etc.
Do not enter predecessors and resources for new tasks at this stage. These will be entered later.
Avoid entering or updating Start and Finish dates yourself. Let these be calculated by MS Project based on
dependencies.
You can uniformly load administrative tasks i.e. avoid setting any other tasks contours.
4.5 Step-5: Enter tasks relationship
Follow guidelines given in "Dependencies between Tasks".
All non summary tasks should have predecessors or successors or both but should not use Summary tasks
as dependencies.
Doc Ref No: 1-12
Page 9 of 19

Never associate a Summary Task to another Summary Task. Associate dependencies only among tasks.
MS Project builds critical path only using tasks i.e. dependencies of summary tasks are not reflected in
Critical Path.
4.6 Step-6: Assign Resources and allocation Units
Use 'Window Split" to enter resource assignments. Enter work hours and / or units as the estimates are
available. Sometimes you may need to re-adjust task duration.
Finetune allocation to get desired duration.
4.7 Step-7: Do resource levelling
More for information on Resource Loading refer to "Availability" and "Leveling" under "Resources".
4.8 Step-8: Enter Task Codes and Task Leader Resource names
Entering of Task Code and Lead Resource information is not required for schedule development. It is
meant only for using procject schedule data for further automation. You may ignore this if not needed.
Refer to "Field reserved for use" to understand the use of Task Code.
Task code is a text field. Enter 1 as 01 or 001 or 0001 depending unpon the total number of tasks in the
project schedule.
Refer to "Lead Resource" under "Resource" for information on Lead Resource.
4.9 Step-9: Test automation tools if any
If you have automation tools for tasks status collection and project performance reporting, test these tools
to check if all required information have been entered.
This testing should always be done before schedule approval and / or actual use of automation tools
4.10 Step-10: Review and update
Before you send the project schedule for review, ensure that the project schedule has been developed
adhering to guidelines.
If you require some specific inputs from reviewers, you should clearly specify these expectations addressed
to specific resources. You may inform reviewers the information that can not change i.e. already finalized.
This will increase the review effectiveness.
4.11 Step-11: Baselines
Refer "Baseline" for further information.
Baseline is useful even if EVA is not required.
4.12 Step-12: Schedule Approval
Approval ensures that project schedule has covered the total scope of project. However, Project Schedule
is dynamic entity. It will change from day to day as project progresses.
Project Schedule will need re-approval for major scope changes.
5 Task Details
5.1 Task Duration = Days
Preferably enter duration in days only, with 1 day as minimum for tasks and 0 day for milestones. In
exceptional cases, use hours or weeks as units for task duration.
Avoid mixing of duration units while entering tasks duration such as 2 hours for one task and 3 days for
another task.
Doc Ref No: 1-12
Page 10 of 19

Duration of non summary task may not exceed 10 work days or two weeks except for tasks such as
coordination, management, monitoring which needs a resource to work daily or at regular intervals or on
demand, may not follow any restriction.
Also Schedules developed for planning purpose only may use any task duration without restriction as these
are not meant for execution but for planning only.
5.2 Task Work = Hours
Work hours are required to be entered only for Tasks Type = Fixed work. For Tasks Type = Fixed Units,
work hours are automatically calculated for a task duration.
Avoid entering work hours such as 2.5 or 4.7 instead enter hours in full numbers. If estimates are not
available, keep this field blank.
5.3 Task type = Fixed work or Fixed units
Do not use task type as Fixed Duration. Also if task work estimates are available, use task type as Fixed
Work. Fixed units are suitable when full time resources are assigned.
EVA calculations have impact from selecting task type. Preferably use Fixed work if EVA calculations are
used.
Avoid mixing Task Types.
5.4 Constraints Type = As Early as possible
Set Constraint type as "As early as possible" except in situations such as external dependencies, mandated
start or finish dates.
Use other constraints with caution and knowledge.
5.5 Task Description size
Describe task in brief. Recommended maximum size is 50 characters. Do not use Hyperlinks in tasks
description. Give additional task details in Notes.
Avoid using undocumented or uncommon abbreviations.
5.6 Task Notes
Use Task Notes to describe task in detail as required. Mention risks and dependencies descriptively or any
other important information.
5.7 Task Relationship
Use Predecessors field to enter task dependencies. Avoid entering dependencies in Successors field.
Successors will be built automatically by MS Project if predecessors are entered or visa versa.
Each task should have a predecessor or successor or both. Normally the tasks that do not have both
predecessor and successor are part of a primary task (on a network path) broken down into smaller tasks.
These tasks look like hanging from the primary task which moves along the network path.
6 Resources
6.1 Names
Use short names of resources, usually one word identification by first or last name.
6.2 Lead Resource
Identify lead resource incase of more than one resource assigned to a task or a representative from
function side if tasks are to be executed under control of a Business Function. Make lead resource
responsible for tasks status updates and coordinating the task.
Doc Ref No: 1-12
Page 11 of 19

Use short names lead resources and enter it in Text1 Field.
6.3 Availability:
If a resource is available for 50% of his work time, do not allocate him for 100%. Use Resource Sheet View
to mention maximum availability of the resources. "
6.4 Leveling:
Normally, resources should not be loaded more than 100% unless commitments for overtime are available.
Use ""Resource Uses View"" for resource leveling."
6.5 Work Completion:
Use % work complete field to enter work completion in increment of 10% i.e. avoid entering 65% instead
enter 70%. Do not use % complete field for this purpose."
6.6 Actual Work:
Do not enter any value in this field."
6.7 Inserting Tasks after baseline:
Create new tasks codes by appending A,B,C etc to the previous code.
6.8 Commitments:
Ensure that the resources from business side are committed by the business unit head. Ensure high level of
commitments.
6.9 Absence Plans:
Ensure Outlook calendars of team are updated with planned absences
6.10 Replacements:
Ensure resource replacements are palnned.
7 Calendar settings:
Week Starts at Saturday:
Weekly off days: Thursday and Friday:
Office Time: 8 am to 5 pm:
Holidays: as per Riyad Bank :
8 Dependencies between tasks:
8.1 nFS (Finish to Start. Example 6FS):
nFS type relationship determines that this task can not start until nth task finishes i.e. the start date of this
task to be equal to the finish date of nth task. FS is the most frequently used relationship in forward
scheduling. For an example you can not test a code until it's not build.
8.2 nSS (Start to Start. Example 10SS):
nSS type relationship makes the start date of this task same as the start date of nth task.
This happens when various circumstances like feasibility of parallel execution and availability of resources,
tasks needs inputs from other executing tasks simultaneously, in case of forced schedule crashing etc.
Doc Ref No: 1-12
Page 12 of 19

8.3 nFF (Finish to Finish. Example 18FF):
nFF type relationship determines the finish date of this task to be equal to the finish date of nth task. It is
used when two or more tasks need to be finish together. This happens when finishing of one task depends
on finishing of other task. FF relationship helps in synchronization of finish of two or more tasks. For
example preparation of a document finishes along with document review and subsequent updates and
reviews and so on.
In FF relationship the start date of a task is governed by the task duration and project start date. In any
case, start date of task can not be earlier to project start date.
8.4 nSF (Start to Finish. Example 29SF):
nSF type relationship determines the finish date of this task equal to the start date of nth task. It occurs
when a task is not considered finished if another task is not started. This a tight coupling situation i.e.
maintaining perfect continuity is a must. For example for 24 hour operations, day shift operator can not
leave until the night shift operator takes over his duties.
+ n d (Late by n days. Example 6FS+2d):
It is used to delay start or finish of a task. In example 6FS+2d, task start is delayed by 2 days.
- n d (Early by n days. Example 27FF-5d):
It is used to early start or finish of a task. In example 6FF-5d, task will finish by 5 days earlier.
9 Baselines:
Set first Baseline at the time of PMP approval:
Set second Baseline after Final Design Approval:
Third or any further baselines are to be set only in case of major scope changes after second baseline.
If tasks are added after the base lining, you should re-baseline only that tasks and associated summary tasks
at all higher levels.
10 Approval:
Schedule Review is required before each approval:
Schedule Approval required before PMP approval:
Schedule Approval required before each base lining:
Schedule Approval required for major scope change
Schedule Approval not required for adding / deleting tasks, updating duration, dependencies, resource
assignment updates etc as part of day to day Schedule Maintenance.:
11 Fields reserved for use:
If your scheduling tool provide use of custom field and some of these custom fields are to be reserved to
meet project reporting requirements, ensure that the list of these fields in given in Schedule development
guidelines so that schedulers can avoid using those fields. If the information about reserved fields is not
available, you should avoid using first 10 fields in the category such as Text, Numeric, Dates etc.
Some examples of fields reserved for use:
Text1 is reserved for use to store name of the Lead Resource: Lead Resource is the resources who leads the
task team and reports tasks status.
Text2 is reserved for use to store task code or accounting code: Task Code is used to uniquely identify a
task during the whole project life cycle. it is assigned when a new task is added to project schedule. A Task
Code does not change if some tasks are deleted or relocated in schedule.
Text3 is reserved for use for storing EVA group codes: EVA Group Code is used for EVA calculations
Doc Ref No: 1-12
Page 13 of 19

Text4 is reserved for storing task status code or comments: Task Status Code
Text5 is reserved for use to store name of a person who is not part of the project team i.e. there are no
assigned resources, work hours are 0 but task has a duration.
Number1 is reserved for EVA calculations: Earned Value calculated by Macro (EVC)
Number2 is reserved for EVA calculations: This field is also used by EVA
Any other first 10 fields are reserved for future use: Do not use first 10 fields
12 Addressing Security Issues
Securing Schedules during development and rest of the project life cycle is very important. You must ensure
that the following concerns are addressed.
Project Schedules should be automatically classified as “confidential” and must be treated according to the
rules for securing confidential documents spelled out in Security Policy. The following is an example of such
security rules.
Project schedules must be stored safely and must not be disclosed to anyone who does not have a clear
need.
Schedules may be kept on a laptop (or desktop) if encryption is used. It is advised to Safeboot installed.
It’s acceptable to work remotely using a secure connection such as VPN
The Outlook Web Access may be used for non-classified correspondence, but not for sending schedules as
attachments.
When printed, project schedules must bear the statement “Confidential” (all centrally-maintained print
templates should be set up with the appropriate wording).
13 Schedules Inventory
It is useful to maintain an inventory of schedules which can be maintained the PMO or quality assurance
function. MS EPM or SharePoint or other tools can be used as inventory storage. Inventory records may
include the following information:
Schedule name
Schedule description
Schedule owner
Project Planner
Plan status
14 Definitions and Terms used in Schedule Development
Activity and Task: A clearly bounded unit of work that either produces something or advances the project in
some significant way. Activities can be subdivided into steps generally produce deliverable components is
called task. For example Testing is activity and creation of test cases is task.
Assumption: Factors used in the planning process that are considered true, real or certain but cannot be
proven. An assumption may have some degree of risk associated with it.
Base Plan: The components of a Project Plan which can be expected to remain static throughout the project
and would require a re-authorization of the Plan if a change should be required, e.g. Project Approach, Major
Milestone Dates, or overall budget/cost estimates.
Baseline: The original plan (for a project, a work package, or an activity), plus or minus approved changes.
Usually used with a modifier (e.g. cost baseline, schedule baseline, performance measurement baseline).
Constraint: A factor which will limit the project team's options in regard to the management of the project or
the development of the project deliverables. Can be categorized as impacting either Business, Technical or
Project Delivery. As an example, a predefined budget is a constraint that is likely to limit the team's options
regarding scope, staffing, and scheduling. In scheduling terms, constraints dictates such as must finish by
this data, must use only the available resources and tools etc.
Doc Ref No: 1-12
Page 14 of 19

Contingency Planning: The development of a management plan that identifies alternative strategies to be
used to ensure project success if specified risk events occur.
Contingency Reserve: A separately planned quantity used to allow for future situations which may be
planned for only in part (sometimes called ""known unknowns""). For example, rework is certain, the amount
of rework is not. Contingency reserves may involve cost, schedule, or both. Contingency reserves are
intended to reduce the impact of missing cost or schedule objectives. Contingency reserves are normally
included in the project's cost and schedule baselines.
Crashing: Taking action to decrease the total project duration after analyzing a number of alternatives to
determine how to get the maximum duration compression for the least cost.
Critical Activity: Any activity on a critical path. Not in the context of complexity and importance.
Critical Path: In a project network diagram, the series of activities which determines the earliest completion
of the project. Activities on critical path, if delayed, will delay the completion of the project. The critical path
will generally change from time to time as activities are completed ahead of or behind schedule.
Critical Path Method: A network analysis technique used to predict project duration by analyzing which
sequence of activities (which path) has the least amount of schedule flexibility (the least amount of float).
Early dates are calculated by means of a forward pass using a specified start date. Late dates are calculated
by means of a backward pass starting from a specified completion date (usually the forward pass's early
finish date).
Deliverable: Any measurable, tangible, verifiable outcome, result, or item that must be produced to complete
a project or part of a project. A deliverable is subject to approval by the project sponsor or customer.
Dependency: Anything that relies on something else to meet an objective. In a project context, any activity
which relies on the performance of another activity for completion. Dependencies may be either internal or
external to the project. Cross-project dependencies (external) have some degree of risk associated with
them due to the lack of control and visibility over the external project. Dependencies may be listed as either
a fact/constraint, assumption or risks, depending on the level of uncertainty and control.
Duration: The number of work periods (not including holidays or other non-working periods) required to
complete an activity or other project element. Usually expressed as workdays or workweeks. Sometimes
incorrectly equated with elapsed time.
Duration Compression: Shortening the project schedule without reducing the project scope. Duration
compression is not always possible and often requires an increase in project cost.
Estimation: Estimation in project context refers to estimates of work effort, schedule Duration, resource units
and project cost. Effort estimates are expressed in units of work such as person-hours or person-days or
person-weeks or person-months. Duration estimates are expressed in units time such as hours, days, weeks
or months. Duration estimates includes only the time for work days i.e. weekly offs and holidays are not part
of duration estimates. Estimates of resource units are in terms of number of persons. Effort, Duration and
Resource Units are related through the following equation.
Effort = Duration multiplied by Resource Units
Earned Value: A method for measuring project performance. It compares the amount of work that was
planned with what was actually accomplished to determine if cost and schedule performance is as planned.
Effort: The number of labour units required to complete an activity or other project element. Usually
expressed as person-hours, person-days, or person-weeks etc. Person-days or man-days or staff-days
means the same thing.
Float: The amount of time that an activity may be delayed from its early start without delaying the project
finish date. Float is a mathematical calculation and can change as the project progresses and changes are
made to the project plan.
Issue: For purposes of Project Management planning, an issue is a question (uncertainty) concerning parts
of a project that requires an answer or a decision to be made in order to perform an activity or meet an
objective of the project. Issues are resolved by the assignment of an owner who will research and document
the issue and report on possible impacts and any associated risks (see Risk) or need for a change in the
project's scope, time, and/or cost.
Milestone: A significant event in the project, usually completion of a major (key) deliverable.
Doc Ref No: 1-12
Page 15 of 19

Mitigation: Taking steps to lessen risk by lowering the probability of a risk event's occurrence or reducing its
effect should it occur.
Node: One of the defining points of a network; a junction point joined to some or all of the other dependency
lines.
Precedence Diagramming Method: A network diagramming technique in which activities are represented
by boxes (nodes). Activities are linked by precedence relationships to show the sequence in which the
activities are to be performed.
Product Breakdown Structure (PBS): A hierarchical grouping of project deliverables which organizes and
defines the total scope of the project deliverables. Each descending level represents an increasingly detailed
definition of a deliverable.
Project Dependencies: Any project which has an activity that is dependent upon an activity being performed
by another project within the same organization, has a project dependency. These dependencies should be
noted and accounted for in the Project Plan to ensure synchronous activity linking in the Schedule.
Project Influences: Any fact/constraint, risk, or assumption which impacts the management or
implementation of the project is an ""influence"" in regard to the planning of the project. These should be
identified early on in the Planning Process and referred to when developing the Plan.
Project Network Diagram: Any schematic display of the logical relationships of project activities. Always
drawn from left to right to reflect project chronology.
Project Phase: A collection of logically related project activities, usually culminating in the completion of a
major deliverable.
Project Plan: A formal, approved document (usually consisting of many sub-documents) used to guide both
project execution and project control. The primary uses of the project plan are to document planning
assumptions and decisions, to facilitate communication among stakeholders, and to document approved
scope, cost and schedule baselines.
Reserve: A provision in the project plan to mitigate cost and/or schedule risk. Often used with a modifier
(e.g. management reserve, contingency reserve) to provide further detail on what types of risk are meant to
be mitigated.
Resource: Personnel, equipment, and/or materials that are used in the execution of a project activity for the
purpose of achieving an event.
Resource Levelling: Any form of network analysis in which scheduling decisions (start and finish dates) are
driven by resource management concerns (e.g. limited resource availability or difficult to manage changes in
resource levels).
Resource Limited Schedule: A project schedule whose start and finish dates reflect expected resource
availability. The final project schedule should always be resource limited.
Resource Planning: Determining what resources (people, equipment, materials) are needed in what
quantities to perform project activities.
Risk: Any factor, situation, characteristic, or condition which may cause the project to be unsuccessful, or
less than successful. For example, utilizing a great deal of new technology on a project whose completion
date is critical represents a risk.
Risk Event: A discrete occurrence that may affect the project for better or worse.
Risk Identification: Determining which risk events are likely to affect the project.
Risk Quantification: Evaluating the probability of risk event occurrence and effect or level of impact of that
event on the project.
Risk Response Control: Responding to changes in risk over the course of the project.
Risk Response Development: Defining enhancement steps for opportunities and mitigation steps for
threats.
Slack: In network-oriented project management techniques, the difference in time between the latest start
time and the earliest start time for any given activity. Represents the amount of additional time that an
activity might consume without affecting the completion time of the overall project.
Doc Ref No: 1-12
Page 16 of 19

Walkthrough: A group review of a program or document prior to its release. The review is performed as
soon as possible after the product is created in order to detect errors.
Work Breakdown Structure (WBS): A deliverable-oriented grouping of project elements which organizes
and defines the total scope of the project. Each descending level represents an increasingly detailed
definition of a project component. Project components may be products or services.
Work Package: A deliverable at the lowest level of the Work Breakdown Structure. A work package may be
divided into activities.
Work Product: Any final or intermediate product, service, or result of a process or activity.
Doc Ref No: 1-12
Page 17 of 19

15 Appendix-A
Xx
16 References
17 Glossaries
The glossary entries in this section are specific to this document. ……
Abbreviation Description
Doc Ref No: 1-12
Page 18 of 19

18 Document Control
Access Control and Distribution
Xx
Approved by
Name Designation Date Signature
Abdullah Alserani Business Strategy
Consultant
Released by
Name Designation Date Signature
Ashok Kumar LalSingh
Reviewed by
Name Designation Review Aspect
Abdullah Alserani Business Strategy
Consultant
All aspects
Changes Summary Log
Issue No Date Changed by Changes summary
1 First time release
Doc Ref No: 1-12
Page 19 of 19

Project Schedule Development Guidelines

More Related Content

Viewers also liked

Similar to Project Schedule Development Guidelines

More from Ashok Kumar

Project Schedule Development Guidelines