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-1Copyright © Taajeer Co., KSAWebsite: 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.

http://www.taajeer.com/

Project Schedule Development Guidelines v1.0

Index

1 Introduction....................................................................................................................................... 42 Inputs to Schedule development.......................................................................................................4

2.1 Project Management Methodology...........................................................................................42.2 PBS (Product Breakdown Structure), WBS and Network diagrams............................................42.3 Project Network Diagram...........................................................................................................42.4 WBS (Work Breakdown Structure) and Work Packages.............................................................52.5 Project Schedule Templates.......................................................................................................52.6 Planning Levels...........................................................................................................................52.7 Schedule Ownership and responsibilities...................................................................................6

3 Steps for developing a Project Schedule............................................................................................63.1 Quality Assurance, Administration, Issues and Risks..................................................................63.2 Dependencies.............................................................................................................................7

3.2.1 External dependencies.......................................................................................................73.2.2 Correct Dependencies........................................................................................................73.2.3 Lead Resources...................................................................................................................7

4 Steps to create MS Project Schedule.................................................................................................74.1 Step-1: Ensure correct MS Project settings................................................................................74.2 Step-2: Enter Project Information..............................................................................................84.3 Step-3: Create Schedule Structure.............................................................................................84.4 Step-4: Enter Tasks and task details...........................................................................................84.5 Step-5: Enter tasks relationship.................................................................................................84.6 Step-6: Assign Resources and allocation Units...........................................................................84.7 Step-7: Do resource levelling......................................................................................................94.8 Step-8: Enter Task Codes and Task Leader Resource names......................................................94.9 Step-9: Test automation tools if any..........................................................................................94.10 Step-10: Review and update......................................................................................................94.11 Step-11: Baselines......................................................................................................................94.12 Step-12: Schedule Approval.......................................................................................................9

5 Task Details........................................................................................................................................ 95.1 Task Duration = Days.................................................................................................................95.2 Task Work = Hours..................................................................................................................... 95.3 Task type = Fixed work or Fixed units.......................................................................................105.4 Constraints Type = As Early as possible....................................................................................105.5 Task Description size................................................................................................................105.6 Task Notes................................................................................................................................105.7 Task Relationship..................................................................................................................... 10

6 Resources.........................................................................................................................................106.1 Names...................................................................................................................................... 106.2 Lead Resource..........................................................................................................................106.3 Availability:...............................................................................................................................106.4 Leveling:................................................................................................................................... 106.5 Work Completion:....................................................................................................................116.6 Actual Work:.............................................................................................................................11


Doc Ref No: 1-12

Page 2 of 19



6.7 Inserting Tasks after baseline:..................................................................................................116.8 Commitments:..........................................................................................................................116.9 Absence Plans:......................................................................................................................... 116.10 Replacements:..........................................................................................................................11

7 Calendar settings:.............................................................................................................................118 Dependencies between tasks:..........................................................................................................11

8.1 nFS (Finish to Start. Example 6FS):...........................................................................................118.2 nSS (Start to Start. Example 10SS):...........................................................................................118.3 nFF (Finish to Finish. Example 18FF):........................................................................................118.4 nSF (Start to Finish. Example 29SF):.........................................................................................12

9 Baselines:......................................................................................................................................... 1210 Approval:......................................................................................................................................1211 Fields reserved for use:................................................................................................................1212 Addressing Security Issues...........................................................................................................1313 Schedules Inventory.....................................................................................................................1314 Definitions and Terms used in Schedule Development................................................................1315 Appendix-A...................................................................................................................................1716 References................................................................................................................................... 1717 Glossaries.....................................................................................................................................1718 Document Control........................................................................................................................18


Doc Ref No: 1-12

Page 3 of 19



1 IntroductionProject 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 developmentTo 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 MethodologySchedule 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 diagramsFor 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 DiagramProject 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 PackagesWBS 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 LevelsProject 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 responsibilitiesSchedule 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 ScheduleThe 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 RisksThere 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)


Doc Ref No: 1-12

Page 7 of 19



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 dependenciesExternal 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 CorrectnessEnsure 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 ResourcesIdentify 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 settingsThe 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 InformationAfter 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 StructureCreate 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 detailsFor 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 relationshipFollow 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 UnitsUse '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 levellingMore for information on Resource Loading refer to "Availability" and "Leveling" under "Resources".

4.8 Step-8: Enter Task Codes and Task Leader Resource namesEntering 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 anyIf 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 updateBefore 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: BaselinesRefer "Baseline" for further information.

Baseline is useful even if EVA is not required.

4.12 Step-12: Schedule ApprovalApproval 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 = DaysPreferably 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 = HoursWork 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 unitsDo 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 possibleSet 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 sizeDescribe 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 NotesUse Task Notes to describe task in detail as required. Mention risks and dependencies descriptively or any other important information.

5.7 Task RelationshipUse 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 NamesUse short names of resources, usually one word identification by first or last name.

6.2 Lead ResourceIdentify 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 IssuesSecuring 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 InventoryIt 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 DevelopmentActivity 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-AXx

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 DistributionXx

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


Documents

Project Schedule Development Guidelines