Creating Project Schedule Standards v1.0
Creating
Project Schedule
Standards
v1.0
Author: AshokKumar LalSingh
20 April 2009
Copyright Notice
This document describes the tips for creating Project Schedule standards or guidelines. RASS Tools
Limited reserves all rights to modify the content of this document. The reproduction of this document in
part or full without the explicit authorization from RASS Tools Limited is not permitted. You can use this
document for your personal purpose and distribute it without changes.
© RASS Tools Limited, UK
20 April 2009
Page 1 of 24
Creating Project Schedule Standards v1.0
Index
1
Inputs to Schedule Development ........................................................................................................4
1.1
Project Management Methodology ......................................................................................................................................... 4
1.2
PBS (Product Breakdown Structure), WBS and Network diagrams ......................................................................................... 4
1.3
Project Network Diagram ........................................................................................................................................................ 5
1.4
WBS (Work Breakdown Structure) and Work Packages ......................................................................................................... 6
1.5
2
Project Schedule Template ..................................................................................................................................................... 6
Steps for developing a Project Schedule ...........................................................................................6
2.1
Quality Assurance, Administration, Issues and Risks .............................................................................................................. 8
2.2
Dependencies ........................................................................................................................................................................ 9
2.3
Lead Resources ................................................................................................................................................................... 10
3
Steps to create MS Project Schedule ................................................................................................10
3.1
Step-1: Ensure correct Options settings................................................................................................................................ 10
3.2
Step-2: Enter Project Information .......................................................................................................................................... 11
3.3
Step-3: Create Schedule Structure ....................................................................................................................................... 11
3.4
Step-4: Enter Tasks and task details .................................................................................................................................... 11
3.5
Step-5: Enter tasks relationship ............................................................................................................................................ 11
3.6
Step-6: Assign Resources and allocation Units ..................................................................................................................... 12
3.7
Step-7: Do resource levelling ................................................................................................................................................ 12
3.8
Step-8: Enter Task Codes and Task Leader Resource names .............................................................................................. 12
3.9
Step-9: Test automation tools if any ...................................................................................................................................... 12
3.10
Step-10: Review and update................................................................................................................................................. 13
3.11
Step-11: Baselines ............................................................................................................................................................... 13
3.12
Step-12: Schedule Approval ................................................................................................................................................. 13
4
Task Details .........................................................................................................................................13
4.1
Task Duration = Days .......................................................................................................................................................... 13
4.2
Task Work = Hours ............................................................................................................................................................... 14
4.3
Task type = Fixed work or Fixed units................................................................................................................................... 14
4.4
Constraints Type = As Early as possible ............................................................................................................................... 14
4.5
Task Description size ........................................................................................................................................................... 14
4.6
Task Notes ........................................................................................................................................................................... 14
4.7
5
Task Relationship ................................................................................................................................................................. 15
Resources ............................................................................................................................................15
5.1
Names .................................................................................................................................................................................. 15
5.2
Lead Resource ..................................................................................................................................................................... 15
5.3
Availability: ........................................................................................................................................................................... 15
5.4
Levelling: .............................................................................................................................................................................. 15
5.5
Work Completion: ................................................................................................................................................................. 16
5.6
Actual Work: ......................................................................................................................................................................... 16
5.7
Inserting Tasks after baseline: .............................................................................................................................................. 16
5.8
Commitments: ...................................................................................................................................................................... 16
5.9
Absence Plans: .................................................................................................................................................................... 16
5.10
Replacements: ..................................................................................................................................................................... 16
6
7
Calendar settings: ...............................................................................................................................16
Dependencies between tasks.: ..........................................................................................................17
7.1
nFS (Finish to Start. Example 6FS): ..................................................................................................................................... 17
7.2
nSS (Start to Start. Example 10SS): ..................................................................................................................................... 17
7.3
nFF (Finish to Finish. Example 18FF): .................................................................................................................................. 17
7.4
nSF (Start to Finish. Example 29SF): ................................................................................................................................... 17
8
Baselines: ............................................................................................................................................18
© RASS Tools Limited, UK
20 April 2009
Page 2 of 24
Creating Project Schedule Standards v1.0
9 Approval:..............................................................................................................................................18
10 Fields reserved for use:......................................................................................................................18
11 Definitions and Terms used in Schedule Development ..................................................................19
© RASS Tools Limited, UK
20 April 2009
Page 3 of 24
Creating Project Schedule Standards v1.0
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 standards
for promoting best planning practices. The purpose of this document is to highlight some of these
practices. As planning requirements may vary from organization to organization, best scheduling practices
may also vary from organization to organization. The tips described in this document may not be
applicable uniformly to all organizations. You can 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.
1
Inputs to Schedule development
1.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 extend if your organization uses a Project
Management Methodology, particularly for the following:

Identification of deliverables required to executes 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.

1.2
High level default WBS is readily available from Project Management Methodology.
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.
© RASS Tools Limited, UK
20 April 2009
Page 4 of 24
Creating Project Schedule Standards v1.0
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 this document.
1.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 analysing 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.
© RASS Tools Limited, UK
20 April 2009
Page 5 of 24
Creating Project Schedule Standards v1.0
1.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 reorganised 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 optimise resource utilization. Ensure that WBS Work
Packages are correctly associated along with network paths. Discussion on WBS and Work Packages is
out of scope of this document.
1.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.
1.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
© RASS Tools Limited, UK
20 April 2009
Page 6 of 24
Creating Project Schedule Standards v1.0
1 project schedule at programme level, level 2 project schedule at release level, level 3 project schedule
at discipline level.
1.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 standards.
2
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.
© RASS Tools Limited, UK
20 April 2009
Page 7 of 24
Creating Project Schedule Standards v1.0

Assign resources and work hours required by resource to tasks. Identify maximum allocatable
time in percent for each resource before assigning resources
2.1

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 levelling

Get schedule approved by required stakeholders

Baseline schedule. Before base lining, make a backup copy of schedule.
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)
 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%.
© RASS Tools Limited, UK
20 April 2009
Page 8 of 24
Creating Project Schedule Standards v1.0
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.
2.2
Dependencies
2.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.
2.2.2
Correct Dependencies
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.
© RASS Tools Limited, UK
20 April 2009
Page 9 of 24
Creating Project Schedule Standards v1.0
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 levelling.
3
Steps to create MS Project Schedule
3.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 standards 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 standards 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.
© RASS Tools Limited, UK
20 April 2009
Page 10 of 24
Creating Project Schedule Standards v1.0
3.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.
3.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.
3.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.
3.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.
© RASS Tools Limited, UK
20 April 2009
Page 11 of 24
Creating Project Schedule Standards v1.0
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.
3.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.
3.7
Step-7: Do resource levelling
More for information on Resource Loading refer to "Availability" and "Leveling" under "Resources".
3.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.
3.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
© RASS Tools Limited, UK
20 April 2009
Page 12 of 24
Creating Project Schedule Standards v1.0
3.10
Step-10: Review and update
Before you send the project schedule for review, ensure that the project schedule has been developed
adhering to standards.
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.
3.11
Step-11: Baselines
Refer "Baseline" for further information.
Baseline is useful even if EVA is not required.
3.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.
4
Task Details
4.1
Task Duration = Days
Preferably enter duration in days only, with 1 day as minimum for tasks and 0 day for milestones. In
expectional 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.
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.
© RASS Tools Limited, UK
20 April 2009
Page 13 of 24
Creating Project Schedule Standards v1.0
4.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.
4.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.
4.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 contraints with caution and knowedge.
4.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 abbriviations.
4.6
Task Notes
Use Task Notes to describe task in detail as required. Mention risks and dependencies descrptively or any
other important information.
© RASS Tools Limited, UK
20 April 2009
Page 14 of 24
Creating Project Schedule Standards v1.0
4.7
Task Relationship
Use Predecessors field to enter task dependencies. Avoid entering dependencies in Successors field.
Successors will be built autumatically 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 haging from the primary task which moves along the network path.
5
Resources
5.1
Names
Use short names of resources, usually one word identification by first or last name.
5.2
Lead Resource
Identify lead resource incase of more than one resource assigned to a task or a representative from
funcation side if tasks are to be executed under control of a Function in Riyad bank. Make lead resource
responsible for tasks status updates and coordinating the task.
Use short names lead resources and enter it in Text1 Field.
5.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 availablity of the resources. "
5.4
Levelling:
Normally, resources should not be loaded more than 100% unless commitments for overtime are
available. Use ""Resource Uses View"" for resouce leveling."
© RASS Tools Limited, UK
20 April 2009
Page 15 of 24
Creating Project Schedule Standards v1.0
5.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."
5.6
Actual Work:
Do not enter any value in this field."
5.7
Inserting Tasks after baseline:
Create new tasks codes by appending A,B,C etc to the previous code."
5.8
Commitments:
Ensure that the resources from business side are committed by the business unit head. Ensure high level
of commitments. "
5.9
Absence Plans:
Ensure Outlook calendars of team are updated with Planned absences"
5.10
Replacements:
Ensure resource replacements are palnned."
6
Calendar settings:
Week Starts at Satarday:
Weekly off days: Thursday and Friday:
Office Time: 8 am to 5 pm:
Holidays: as per Riyad Bank :
© RASS Tools Limited, UK
20 April 2009
Page 16 of 24
Creating Project Schedule Standards v1.0
7
Dependencies between tasks.:
7.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.
7.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.
7.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.
7.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.
© RASS Tools Limited, UK
20 April 2009
Page 17 of 24
Creating Project Schedule Standards v1.0
- 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.
8
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.
9
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.:
10
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:
© RASS Tools Limited, UK
20 April 2009
Page 18 of 24
Creating Project Schedule Standards v1.0
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
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
11
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).
© RASS Tools Limited, UK
20 April 2009
Page 19 of 24
Creating Project Schedule Standards v1.0
12
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:
13

Schedule name

Schedule description

Schedule owner

Project Planner

Plan status
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.
Contingency Planning: The development of a management plan that identifies alternative strategies to
be used to ensure project success if specified risk events occur.
© RASS Tools Limited, UK
20 April 2009
Page 20 of 24
Creating Project Schedule Standards v1.0
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 persondays 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
© RASS Tools Limited, UK
20 April 2009
Page 21 of 24
Creating Project Schedule Standards v1.0
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.
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.
© RASS Tools Limited, UK
20 April 2009
Page 22 of 24
Creating Project Schedule Standards v1.0
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.
© RASS Tools Limited, UK
20 April 2009
Page 23 of 24
Creating Project Schedule Standards v1.0
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.
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.
© RASS Tools Limited, UK
20 April 2009
Page 24 of 24