project schedule guidelines v1

8/7/2019 Project Schedule Guidelines v1

1/14

LTC MS Project ScheduleGuidelines

Author:

Version: 0.1

Status: Draft

Version Date: March 22, 2011


2/14

LTC MS Project Schedule Guidelines

Revision History

Revision Date Status Author Reviewed

by

Summary of

Changes0.1 March 22, 2011 Draft Initial Draft

- 2 -

Page 2 of 14LTC MS Project Schedule GuidelinesVersion 0.1Revision Date March 22, 2011 2


3/14


Table of Contents

1. INTRODUCTION...................................................................................................................................4

1.1 PURPOSE ...........................................................................................................................................4

2. CONTENT AND APPROACH ..............................................................................................................4

2.1 SCOPEAND OBJECTIVES ................................................................................................................... ....42.2 ASSUMPTIONS.................................................................................................................................. ....42.3 PLANNING....................................................................................................................................... ....4

3. PROJECT SCHEDULE GUIDELINES..................................................................................................5

3.1 WORK BREAKDOWN .................................................................................................................... .........63.2 PLAN.................................................................................................................................................73.3 SUMMARY TASKS..................................................................................................................................93.4 MILESTONES........................................................................................................................................93.5 TASKS..............................................................................................................................................103.6 RESOURCES......................................................................................................................................11

3.8 CALENDARS.......................................................................................................................................134. GENERIC RESOURCES ...................................................................................................................13

5. SCHEDULE CONTINGENCY AND WORK........................................................................................13

5.1 NON-WORKING TIME...........................................................................................................................135.2 WORKING TIME..................................................................................................................................145.3 CONTINGENCY....................................................................................................................................14

- 3 -



4/14


1. Introduction

1.1 Purpose

This document provides guidelines to be applied when developing Microsoft Project schedules withinLTC. These guidelines will support project managers in developing and maintaining accurate

schedules. In addition, they will support resource management by enabling accurate and consistentresource scheduling data within the LTC resource management tool (EPM), the end goal of which isto develop an accurate supply/demand view of people resources across the entire LTC projectportfolio.

2. Content and Approach

2.1 Scope and Objectives

This document details guidelines to be applied to LTC project schedules. They have been introduced

primarily to ensure that accurate and consistent data regarding resource demand is maintained sothat effective resource management can occur at the portfolio level. Project schedules must containthe required resource work effort for any individual who is working on the project. In addition, theseguidelines will support the effective allocation of resources within projects and the early identificationof schedule changes that may impact project and resource commitments. Other concerns, such ascost tracking are not addressed by this document.

2.2 Assumptions

This document assumes that the reader has a good working knowledge of Microsoft Project and anunderstanding of project planning and scheduling techniques.

2.3 Planning

Deliverable-based planning or planning by work component provides an effective approach toproject planning. It is the method that enables the team to define the project or work stream todeliver, to provide the success criteria to the people working on the individual work streams, andto monitor and control progress. A deliverable is any input to or output from a work component orthe project.

Deliverables may be:

Management deliverables, which are produced as part of the management and control of thework component or project, for example, the project charter.

Specialist deliverables, which are those products that make up or used in the delivery of the finaldeliverable, for example, the infrastructure blueprint.

Quality deliverables, which are produced for or by the quality process, for example, the test

results log.

Planning is an iterative process that is carried out at during all phases of a project. As the projectand individual work streams evolve, it is essential that the Microsoft Project schedule be revisedto address and reflect the inevitable changes that occur during the life of the work. This

- 4 -



5/14


document focuses on the population of line items within a Microsoft Project schedule to supportthose aspects that are key to managing resources.

3. Project Schedule Guidelines

The guidelines are described/categorized in relation to the following items:

Work Breakdown

Plan

Summary Tasks

Milestones

Tasks

Resources

Calendars

The column marked Field identifies, where appropriate, the MS Project field affected by the givenguideline. Recommended practices are identified under the SuggestedGuidelines heading.Conformance to the guidelines will help to support LTC in its movement toward greater projectmanagement maturity.

- 5 -



6/14


3.1 Work Breakdown

The term Work Breakdown here is not intended to refer to any artifact (diagram, document, etc.)that may be external to an MS project schedule. Within the context of this document, references toWork Breakdown should be interpreted to mean the totality of work represented within a projectschedule (and appearing within the hierarchical Task Name field/column within MS Project). This

term is introduced here, as an alternate to Work Breakdown Structure or WBS so that it is notconfused with that artifact.

- 6 -


Suggested Guidelines

ID Field Recommended Practice Notes

1. N/A The Work Breakdown must represent100% of the deliverables andactivities defined by the project scopeand capture all deliverablesinternal,external, and interimto becompleted, including projectmanagement.

2. N/A Work Breakdown elements must bedecomposed hierarchically to a levelof detail that is sufficient to identify allresource Work Effort required and tomanage the work of the project.

It is not necessary for all WorkBreakdown elements to bedecomposed to the same level ofdetail.

3. N/A Work Breakdown elements must bedecomposed to a level of detail that issufficient to track work at theappropriate level (individual,subcontractor or org unit).

Ideally, Work Breakdown elementsrepresenting work to be performedby internal resources should bedecomposed to work packages thatare performed by a single individual.

4. N/A The Work Breakdown should becreated by the project team with

significant input from subject matterexperts, managers and other projectstakeholders.

5. N/A The Work Breakdown should includeall significant reporting mechanismsand reviews.

6. N/A Project Management should berepresented as a high level WBSelement in the hierarchy.


7/14


3.2 Plan

- 7 -




7. N/A All project schedules and templates willbe created using EPM Microsoft ProjectProfessional 2007

The use of any tool other than MSProject (e.g. Excel) will not supportportfolio level resourcesupply/demand planning on EPM2007

8. N/A The schedule must include 100% of theWork Effort required to deliver theproject scope for all work that is to beperformed by those resources withinthe scope of Resource Managementincluding FFS, IT Source e.g. businessanalysts, architects, testers, project

managers etc.

Work Effort of resources not withinthe scope of LTC ResourceManagement does not need to beincluded in the schedule.

9. N/A The schedule must include deliverablesand activities performed by resourcesoutside of LTC (other Clusters, externalcontractors, etc.) at a level of detailsufficient to manage the project andaccurately represent theimpact/relationship of this externallyperformed work to all other projectwork.

10. Baselinefields

The schedule must be initiallyapproved and then baselined once theIntegrated Project Plan has beenapproved by the sponsor.

This baseline will be maintained inthe default Baseline field.

Schedules must not be baselineduntil commitments to resourcingand dates have been obtained fromaffected stakeholders.

11. Baselinefields

Schedule line items (tasks, milestones,etc.) should not be deleted /cut fromthe schedule after it has beenbaselined.

Deleting/cutting line items causesthem to be deleted from thebaseline, resulting in the loss ofpossibly useful baseline data to belost.

12. Baselinefields

An approved project change controlaffecting schedule dates or work effortmust be reflected in the schedule by achange to the baseline. Furthermore,

a schedule which has been baselinedmay not be rebase lined without anapproved change control.


8/14


- 8 -



13. N/A Project schedules must be updated ona regular basis, e.g. weel;y. Progressupdates against the schedule shouldbe provided by the resources

performing the work and qualified bythe appropriate technical lead orproject manager.

PM or Coordinator, should applyupdates directly to projectschedule. This may beaccomplished in a variety of ways,

for example:a. Updating Actual Work spent on

each task and thenupdating/defaulting RemainingWork

b. Updating % Complete on eachTask

c. Use the Tools > Tracking>Update Project dialog

14. ScheduleOptions

New Tasks should start on CurrentDate

15. ScheduleOptions

Default Task Type Fixed Work

16. AssignmentRemainingWork

Remaining work updates should begathered from each resource for eachassignment in progress, and theschedule updated accordingly.

Remaining work updates should beapplied at the Assignment level(e.g. Task Usage view)


9/14


3.3 Summary Tasks

3.4 Milestones

- 9 -




17. Resource Resources must not be assigned tosummary tasks.

This can lead to double accountingfor effort if resources are alsoassigned to child/detail tasks.

18. Predecessor Summary tasks should typically nothave predecessors.

Tasks that can start early may bedelayed if the parent summary taskis scheduled late.

19. Successor Summary tasks should typically nothave successors.

Successor tasks that can start earlymay be delayed if the predecessorsummary task is scheduled late.



20. Duration Duration must be zero. A zero duration task will be definedas a milestone. (unless otherwisenoted as per requirements forproject status report).

21. Work Work must be zero. A milestone is a marker whichcontains no work.

22. Resource Resource must never be assignedto milestones.

As there is no work associated with amilestone, it should not appear inany effort or time capture systems.

23. Actual Finish The finish date on key milestones

which represent client committeddates must be updated with theactual dates that these milestonesare completed /achieved.

Enables post-project analysis of

actual versus baselined dates.

24. MilestoneName

Name should be populated as noun+ verb and in the past tense (e.g.Configuration Complete).

Should be product based, describinga measurable state, for example,cabling or configuration completed.For each product delivery orcomponent completion, there shouldbe a milestone.


10/14


3.5 Tasks

- 10 -



11/14


3.6 Resources

- 11 -




25. Work Work must be greater than zero. A zero work task cannot produceanything.

26. Resource All tasks must have a Generic orNamed resource assigned.

This ensures that calculations maybe performed showing resourceforecast.

27. Task type All tasks must be Fixed Work andEffort Driven.

This enables MS Project tocalculate task duration andschedule dates based on workeffort, task relationships and units.

28. N/A Include all of the Work Effortnecessary for the production of aquality deliverable.

29. Work Contingency must not be included in

the Work Effort assigned to tasks.Work assigned to tasks should bebased on the most likely effortrequired by resources to deliver.

Schedule contingency should be

addressed at the milestone level.See section 5. ScheduleContingency and Work.

30. Constraints Constraints should typically not beapplied to tasks. Note: Start No EarlierThan constraints are appliedautomatically by rescheduling.

Dates and durations should alwaysbe driven by predecessors,resource effort and units.

31. Task Name Task name should identify the productit relates to and what it is going toachieve. Name should always bepopulated as verb + noun and in the

present tense, e.g. Create Blueprint.32. N/A Actual Work effort for administrative

activities (e.g. meetings etc) that arebilled to a project should be booked toan administrative task on theschedule.


12/14


3.7

- 12 -




33. Resource All resources must be Named resources,and not Generic resources.

An exception to this rule is when aschedule has been developed with somesegments of it still in draft (and in thiscase, Generic resources may beassociated with tasks that are still indraft).

This ensures that resources knowwhat tasks are assigned to them

and ensures reliable scheduling anddemand forecasting based oncommitted resources for thosedates which have been committed.

34. Resource Work Effort must be quantified for allGeneric and Named resources.

Ensures that resource Work Effort iscontained in the schedule.

35. Resource Generic resources must be based on theEnterprise Generic Resource. Localresources can be manually added.

36. Resource Named LTC resources must be taken

from the Enterprise Resource Pool.

Provides consistency in handling

resources within the pool.37. Resource As a planning basis, resources should be

assigned to tasks up to a maximum of75% allocation in order to account foradministrative and other non-projecttasks that typically occupy a workday.

The 75% allocation applies to thesum total of all assignments for aresource over a given time period(e.g. if a resource is working on twotasks simultaneously during a week,then their total allocation over bothtasks should be approx. 75%).Allocations may vary from thismaximum as project demandsdictate.

38. Resource Multiple Generic resources should beused where applicable to representresources which will later be substitutedby different Named Resources. This willenable schedules with Genericresources to have realistic resourceallocations.


13/14


3.8 Calendars

4. Generic Resources

Where individual resource names are not known during planning, generic resources should be used.Multiple Generic resources may be used on schedules so that Project Managers may later replacethese with different Named resources. Within a given schedule, a Generic resource should not beover-allocated, since this Generic resource will later be replaced by a Named resource.

5. Schedule Contingency and WorkProject Schedules should be developed with work estimates that reflect the most likely effortrequired to complete project tasks, based on the capabilities of the resources assigned. The workeffort assigned to tasks within an MS Project schedule should not include contingency. This is to

ensure that schedule dates/targets for individual tasks are calculated based on the most likely effortrequired by resources to deliver. If by contrast, work effort assigned to tasks includes contingency,then the calculated resource assignments and the project overall will result in schedule dates whichare later than what is most likely. Therefore, schedule contingency must be addressed differently.

Working time and non-working time within a project schedule must be addressed before includingschedule contingency.

5.1 Non-Working Time

All Projects must ensure that the LTC Enterprise Base Calendar is used as it includes statutory andministry approved holidays as non-working time. This ensures that schedule dates take holidays into

consideration. Furthermore, all resources, whether generic or named, should use this base calendar.In addition, project specific non-working time such as planned vacations, town halls, non-projecttraining, contractors off-contract periods, etc. should be reflected in a local calendar as non-workingtime. This will ensure that schedule dates take into consideration any time where resources areunavailable to work on projects.

- 13 -




39. ProjectCalendars

All Projects should apply the EPM BaseCalendar to the project schedule

40. ProjectCalendars

All Projects should ensure that the EPMBase Calendar includes statutory andministry approved holidays as non-working time

Ensures that schedule datestake holidays intoconsideration

41. ResourceCalendars

All Resources, whether Generic orNamed, should use the base calendar

Ensures consistentscheduling


14/14


5.2 Working Time

Work effort estimates for project tasks must be based on the most likely effort required to deliver,based on the capabilities of the resources assigned. This work effort must include all work effortrequired to complete a quality deliverable by the resource, including any planning/analysis time,discussions /consultations with colleagues, etc. The work effort estimate must not include anoverhead for general project administration, such as the submission of timesheets, general email

administration, etc., since this effort will be addressed separately.

Resources assigned to a project full-time should be allocated to tasks on a project schedule up to amaximum of 75% (5.4hrs/day or 27hrs/wk). This figure represents the maximum sum total allocationfor all tasks to which a resource is assigned at any given time (e.g. if Jane is assigned to a projectfull-time with three tasks in a given week, then the sum total of her allocation for that week shouldnot exceed 27hrs). Resources assigned to a project part-time should have their allocations similarlylimited by this 75% Rule (e.g. if Bill is assigned to a project at 50% then his maximum allocationwithin a given week should not exceed 0.5 x 0.75 x 36.25hrs = 13.6hrs).

For resources assigned to a project full-time, this 75% Rule leaves a 25% work effort margin tocover resource activities which are not directly related to specific project tasks, and which may ormay not be billed/charged to a project. This includes time tracking, general email administration,

meetings, etc. There is no need to create a specific task on the project schedule to forecast/planactivities which fall into this 25% margin. For resources assigned to a project part-time, the 75%Rule applied to their project allocation similarly leaves room for these administrative activities.

5.3 Contingency

Once tasks, related dependencies, resource allocations, working time and non-working time areproperly represented in MS Project, the resulting schedule dates will represent the most likelyscenario for delivery and should therefore be used as the schedule targets for the team.Nevertheless, Project Managers must plan for unforeseen circumstances, activities, or estimatingerrors that may result in delays to the schedule.

Risk analysis should be carried out and contingencies allocated on the basis of specific risks whichhave been identified. Notwithstanding this, the amount of contingency to allow within a schedulecan also be derived based on the project size and duration in various ways, such as:

i. Applying a contingency percentage to the project/sub-project/phase duration (e.g. 20%contingency applied to a project phase with duration of 5 months would lead to a schedulecontingency of 1 month).

ii. Calculating a schedule and milestone dates with work effort estimates which initially includecontingency; marking these milestone dates as potential client commitment dates; and thenrecalculating the schedule with contingency amounts removed from the work effort estimatesso that target dates are derived.

It is important to note that contingency should be used to allow for known areas of risk. Contingencyshould not be used to allow for changes in project scope or requirements. Rather, these should gothrough a project change control process.

- 14 -


project schedule guidelines v1

Documents