Project Planning eBG-PD-22-003

Schedule Management Process April 28, 2005

Page 1 OF 11

1.0 Purpose

This Project Schedule Development and Management process document describes the processes required to develop,
approve, and control a project schedule throughout the Planning, Development, and Deployment phases of the Program
Life Cycle (PLC).

The Value of Project Schedule Management:

• Aids Project Manager in monitoring and tracking progress and status of project.
• Allows Project Manager to track and monitor the resource needs of the project.
• Allows project team, stakeholder, and partner’s role to be clearly identified, documented, and ratified.
• Provides a checkpoint to ensure QA requirements are built into the tasks and deliverables of the team.
• Can be used to track and monitor all project related costs.
• Facilitates the risk assessment process.
• Allows the team to effectively identify and manage the critical path.
• Enables the team to crash and fast track the schedule to optimize project timelines.
• Allows Project Manager to effectively monitor and control project scope.
• Provide information that gives Stakeholders confidence in the project team’s progress.

COPYRIGHT © 2005 INTEL CORPORATION. ALL RIGHTS RESERVED.

Project Planning eBG-PD-22-003
Schedule Management Process April 28, 2005
Page 2 OF 11

2.0 Process Flow

Project Manager

3.1
Establish
Project 3.6
Timeline Schedule
Schedule Change
Management and
Control

No PLC Commit Yes

Project Team

3.2 3.3 3.4

3.5
Activity Activity Activity
Schedule Development
Definition Sequencing Estimating

COPYRIGHT © 2005 INTEL CORPORATION. ALL RIGHTS RESERVED.

Project Planning eBG-PD-22-003
Schedule Management Process April 28, 2005
Page 3 OF 11

1
3.0 Process Steps

3.1 Establish Project Timeline

Purpose Establish the project timeline to help the project team understand the timeline boundary conditions.

Entry Criteria • Completed PLC Project Charter from the Program Manager (see Project Handoff Checklist slide
of the PLC Project Charter).
Steps
1. PROGRAM MANAGER: Hand off “Project Handoff Checklist” to Project Manager and establish
high level boundary conditions.

a. The project timeline is created after the Program Manager has handed off the
Project Handoff Checklist to the Project Manager. The Project Manager takes the
information obtained during the handoff and creates the project timeline. At this
stage, the timeline may contain the phases of the PLC and/or a handful of high-
level milestones for each phase. The Project Manager may consult with the
functional area leads or managers to ascertain these milestones, but does not
need to because the milestones are at such a high level. For larger projects, the
estimates at this point in the project are typically estimated by quarter. Smaller
projects will typically be estimated by Work Week.

2. PROJECT MANAGER: Create the high level Project Timeline in the scheduling tool for tracking
purposes.

a. The following illustration is an example of a project timeline:

COPYRIGHT © 2005 INTEL CORPORATION. ALL RIGHTS RESERVED.

Project Planning eBG-PD-22-003
Schedule Management Process April 28, 2005
Page 4 OF 11

b. For large or complex projects, the project timeline may contain only Planning
phase information. This technique can be helpful if the Development and
Deployment phase deliverables are unknown and require further definition that will
occur in the Planning phase. If this approach is taken, the project team would
capture the Development and Deployment milestones in future schedule iterations
as they are identified and documented.

3. PROJECT MANAGER: Review the project timeline with the project leads/managers and obtain
buy-in.

a. If resources for the Planning Phase have not been secured, work with the Program
manager to secure those resources through the resource request process.
(reference eBG-PD-31-Resource Allocation.doc)

b. The eBG Staffing Model may be used as a guideline for developing initial staffing
estimates based on project requirements. The eBG Staffing Model is designed for
projects utilizing the Cascading Waterfall Lifecycle (Ref: eBG-TP-40-Staffing
Model.xls). Document the resulting staffing estimate in the PMP.

4. PROJECT MANAGER: Communicate the project timeline to the project team.

a. This typically happens during a project kickoff.

5. PROJECT MANAGER: Facilitate a meeting with the project team and management to review the
boundary conditions for which the project manager may operate before having to invoke the
corrective action process and rebaseline the schedule. Document any changes to the boundary
conditions in the PMP. Typical boundary conditions are set around Schedule, Cost, and Budget.
Notes
Exit Criteria • Project Timeline is created in the schedule tool

COPYRIGHT © 2005 INTEL CORPORATION. ALL RIGHTS RESERVED.

Project Planning eBG-PD-22-003
Schedule Management Process April 28, 2005
Page 5 OF 11

• Resources are identified and committed for the Planning Phase

3.2 Activity Definition

Purpose Decomposition of project deliverables into activities that must be performed to produce the
product.
Entry Criteria The following are available:
• WBS deliverables have been defined using the Scope Management process
• Project Charter
• Project Requirements
• Historical Information
• Team Expertise
Steps 1. PROJECT TEAM: Identify and document activities.
a. Review each deliverable from the WBS template and decompose it into activities.
b. Activity definition involves identifying and documenting the specific activities that must
be performed to produce the deliverables for a project. The output of this process is the
Work Breakdown Structure (WBS) with associated activities.
2. PROJECT TEAM: Select the work package classification for each activity to support data
collection. Work package classifications are: Engineering, Verification & Validation, and Rework.
a. Engineering applies to activities that build a deliverable
b. Verification & Validation applies to activities that check, review, or inspect a deliverable
c. Rework applies to work done on a deliverable after V&V or the baseline of a deliverable
Notes See Glossary for definitions of Engineering, Verification & Validation, and Rework.

For detailed information regarding how to create the deliverables in a WBS, please see eBG-
PD-21-Scope Definition WBS.doc.

Activity definition typically occurs in the Intel Map Day process or an Iteration Planning session.

See the Process Reference section below for applicable Map Day links.

Gantt templates are available for each Lifecycle to provide a starting point for schedule
development.

Exit Criteria • WBS has activities defined

3.3 Activity Sequencing

Purpose Activity sequencing is the process of placing project activities in a logical, sequential order.

Entry • WBS has activities defined

COPYRIGHT © 2005 INTEL CORPORATION. ALL RIGHTS RESERVED.

Project Planning eBG-PD-22-003
Schedule Management Process April 28, 2005
Page 6 OF 11

Criteria • Team has expertise required to sequence activities

Steps 1. PROJECT TEAM: Order the activities to show sequence and dependency. The best approach for
identifying activities dependencies and correctly placing them in sequential order is to have the person
or group that is most knowledgeable about the activity identify the dependencies and then consult the
rest of the project team for confirmation.
2. PROJECT TEAM: Create the network diagram. Project activity dependencies are best represented in a
network diagram. A project network diagram shows how the project tasks will flow from start to finish.
Network Diagrams can be created manually (i.e., the Intel Map Day wall chart) or with the aid of
software (MS Visio, MS Project).
a. The most common technique for constructing a project network diagram is called the
activity-on-node (AON) method. This technique uses boxes to represent activities and
connects them with arrows that show dependencies. The illustration below is an
example of an activity-on-node network diagram:

Notes Activity sequencing typically occurs in the Intel Map Day process or an Iteration Planning session.

See the Process Reference section below for applicable Map Day links.

Gantt templates are available for each Lifecycle to provide a starting point for schedule development.

Exit • Activity Sequencing is complete

Criteria
• Network Diagram is started

3.4 Activity Estimating

Purpos Activity estimating is the process of analyzing the project activities and assigning estimates to the activities to
e feed into schedule development.

Entry • WBS with activities defined

Criteria
• Resource requirements are identified
• Resource capabilities are identified
• Constraints have been identified
• Assumptions have been identified
• Risks have been identified
• Historical Records are available
• Project team members are available to perform estimates
Steps 1. PROJECT TEAM: Estimate the size and complexity of each activity or deliverable. This may be a software
deliverable or an activity such as developing the product design.
a. A listing of the various standard Size measures are available in the OSP:
b. Complexity can be characterized as High, Medium, Low

COPYRIGHT © 2005 INTEL CORPORATION. ALL RIGHTS RESERVED.

Project Planning eBG-PD-22-003
Schedule Management Process April 28, 2005
Page 7 OF 11

2. PROJECT TEAM: Select the size and effort estimation technique to be used.
a. There are many methods that can be used for estimating size and effort. More than one method
may apply when estimating for a project.
b. Estimation techniques and selection criteria are available in the OSP. When using the Extreme
Programming (XP) Lifecycle, specific guidance for common techniques is explained in eBG-PD-
32-Extreme Programming Estimation Techniques.
c. Document the size mechanism and estimation technique that will be used in the PMP.
3. PROJECT TEAM: Estimate the Activity. The person or group that is most knowledgeable about the activity
should perform the estimates. This is the effort that would be required for a proficient/skilled person to complete
a task assuming that there are no interruptions and normal conditions exist (no learning curve, no unexpected
interruptions). If the activity requires a computing resource, such as hardware or software, estimate the critical
computing resource with the same techniques and document in the PMP. Finally, if the activity requires a
budget consideration, such as travel or consulting, document in the PMP. The project team may utilize the
various tools listed below for estimation.
a. eBG-TL-003-Wideband Delphi Estimation Tool - To facilitate Wideband Delphi estimation
sessions.
b. eBG-TL-004-PERT Estimation Tool - To facilitate collection of estimates using PERT.
c. Business Intelligence Services (BIS) Requirements Gathering Tool (see link in notes section) - To
facilitate requirements gathering and the calculation of effort of resources for the Decision
Support Solutions (DSS) specific elements of projects (ex. Microstrategy & Teradata). This tool
will be used by the BIS Account Management Team.
4. PROJECT TEAM: Update the network diagram with effort estimates.
a. At this point the network diagram has not been optimized to include what-if scenarios such as
adding additional resources, completing activities in parallel, etc.

A B C G
3 2 1 4
START FINISH

D E F
2 9 3

5. PROJECT MANAGER: Document the resource profile in the PMP for the project and request resources
through the resource process.
6. PROJECT MANAGER: Document the assumptions and estimation method in the PMP and reference the
estimation input. Update the project risks as appropriate.
Notes The activity definition, sequencing, estimating, and network diagram are processes that are completed by the
project team during an Intel Map Day session. The Intel Map Day process is well documented and there are
excellent online training sources as well as downloadable processes and templates available. See the
Process Reference section below for applicable Map Day links.

Gantt examples are available for each Lifecycle to provide a starting point for schedule development.

Exit • Estimation technique(s) documented

Criteria
• Risks updated
• Efforts estimates for the activities defined
• Resource demand signal sent to the resource owners

COPYRIGHT © 2005 INTEL CORPORATION. ALL RIGHTS RESERVED.

Project Planning eBG-PD-22-003
Schedule Management Process April 28, 2005
Page 8 OF 11

3.5 Schedule Development

Purpose Schedule development means determining realistic start and finish dates for project activities. The
project schedule is developed and managed in stages, or iterations. As discussed in the sections
above, the first iteration of the project schedule is the project timeline. As the Planning phase
progresses the project schedule will move from a rev 0 state to a rev 1 state as the team’s confidence
in the schedule grows.
Entry Criteria • Activity sequence are complete
• Activity estimates are complete
• Resource allocation response is received with resource skill level
• Project and resource calendars are identified
• Constraints are identified
• Assumptions are identified
• Risk Management Plan is updated and available
Steps 1. PROJECT MANAGER: Create Rev 0 Project Schedule.
a. PM takes the output from the planning session and applies information from the
items available as entry criteria (see above) to optimize and resource load the
schedule. The output of this step is the activity durations and overall project
duration.
i. Revise schedule based on resource skill and specific resource allocation.
The base estimate assumed the skill of the proficient resource. Some
models, templates, and guidelines for applying various factors to
determine a duration estimate can be found at the links below.
1. Duration Estimate Worksheet:
Duration Estimate Guidelines/Instructions:
eBG-GD-005-Schedule Estimation Factors Guideline
2. eBG-TL-005-XP Velocity Calculator - To facilitate the
calculation of Release and Iteration Velocity for XP projects.
b. Define the key milestones for the project that will be used for reporting purposes.
The required milestones are the PLC Decisions and the SDLC Baseline points,
which are indicated in the Gantt templates. Other milestone points can be
identified by the project team.
c. Update the project staffing table in the PMP.
d. During the schedule optimization the Critical Path is identified and managed. For
more information on schedule management techniques (i.e., crashing, fast
tracking, slack, float, and lag) please refer to the PMBOK 2000 reference book. In
addition, other techniques for schedule management, such as Theory of
Constraints, can be used.
2. PROJECT MANAGER: Publish the Rev 0 Project Schedule.
a. The Project Manager establishes a project baseline in the schedule tool based on
the rev 0 key project milestones. The PM publishes the rev 0 schedule in the
schedule tool placing it under Schedule Control (see process step 3.6) and
communicates the information to the team.
i. The project is baselined at this point to:

COPYRIGHT © 2005 INTEL CORPORATION. ALL RIGHTS RESERVED.

Project Planning eBG-PD-22-003
Schedule Management Process April 28, 2005
Page 9 OF 11

1. Collect Performance Reporting data that will be used by the

project team and not used to report current project performance
outside of the project team.
2. Help determine if enough change has happened to warrant
another planning session.
3. Facilitate collection of data for historical records that will be
used in future project planning.
3. PROJECT MANAGER: Manage revisions to the Project Schedule leading to PLC Commit.
a. When a major revision to the schedule is published a project baseline in the
schedule tool is established. Major revisions will typically occur after a Map Day or
Release planning session; any time the schedule end date changes within 2 – 4
weeks; or significant changes to scope or resources.
b. There are no guidelines around the number of baselines a project schedule will
have, however, there may be limits to the number of baselines the schedule tool
can handle. It is the project team’s discretion to determine how to properly
manage the baselines. The number of Schedule Re-plans measure is calculated
by the number of baselines the project uses
c. All baselined project schedules are regularly reviewed and updated with the team
during the project team meetings. Include review of the Schedule Re-Plan
measure.
4. PROJECT MANAGER: Create/Publish the Rev 1 Project Schedule.
a. The Project Manager will facilitate a formal Risk Assessment process with the
team and either agree upon risk reserve to be added to the project schedule or
reduce the scope of the project.
i. A risk reserve is an amount of time that is assigned to activities to
accommodate the schedule related risks in the event that they occur.
The risk reserve analysis process can be conducted with the team after
the risk assessment has occurred. This technique is extremely helpful in
moving the team from a low confidence schedule to a high confidence
schedule.
b. Once the team has a high confidence schedule, the PM will publish and rebaseline
the schedule in the schedule tool as the rev 1 project schedule and obtain a PLC
Commit decision.
i. A schedule with a 90% confidence is an informal guideline highly
recommended by the PLC, although there is no formal documented
process to achieve this number.
Notes
Gantt templates are available for each Lifecycle to provide a starting point for schedule development.

Reference eBG-TP-47-Project Team Meeting Report Out Template.doc for team meeting report out
template.

Schedule Management Techniques: For more information on schedule management techniques (i.e.,
crashing, fast tracking, slack, float, and lag) please refer to the PMBOK 2000 reference book.

For more information on the metrics used for performance reporting, refer to eBG-OS-03-Quality
Assurance Plan.doc.

Resource process defined in eBG-PD-31-Resource Allocation

COPYRIGHT © 2005 INTEL CORPORATION. ALL RIGHTS RESERVED.

Project Planning eBG-PD-22-003
Schedule Management Process April 28, 2005
Page 10 OF 11

Exit Criteria • Key Project Milestones are defined

• Rev 1 project schedule is published and baselined

3.6 Schedule Management and Control

Purpose The process of this activity is to monitor the schedule and manage changes to the schedule after the
Rev 1 schedule has been approved. This includes; identifying, analyzing, documenting, prioritizing,
approving or rejecting, and publishing all schedule related changes that exceed boundary conditions
agreed to by management.
Entry Criteria • Schedule Management Plan is complete
• Rev 1 project schedule is published and baselined
• Change Requests are available for evaluation
Steps 1. PROJECT MANAGER: Monitor the schedule through Project Status Review and Milestone
Review activities.
2. PROJECT MANAGER: Identify changes to project schedule elements that come in through
change request process or notification.
3. PROJECT MANAGER: Review and evaluate the change with project team
a. Project team analyzes the impacted tasks and identifies alternatives to see how
they affect Scope, Schedule, or Resources.
b. If the impact exceeds the boundary conditions agreed to by management, use the
corrective action process and review plan changes with management for approval.
i. Boundary conditions will be managed through the Schedule Variance
and Cost Variance metrics.
4. PROJECT MANAGER: Implement approved change.
a. If change is within the boundary conditions agreed to by management, then the
Project Manager may implement the change as necessary without management
approval.
b. If the change exceeds the schedule boundary condition agreed to by management
at project commit or a subsequent management review, the new project schedule
must be approved by management and rebaselined. A record of the approval
must be recorded and saved in the projects records repository.
5. PROJECT MANAGER: Communicate the decision to the project team and stakeholders.
Notes
Reference eBG-PD-24-Corrective Action Management.doc for the process for Corrective Action
Reference eBG-PC-43-Corrective Action Form.doc for the Corrective Action template.

Exit Criteria • Schedule updates are complete

• Necessary plan updates are complete

4.0 Measures

Number of Schedule Re-plans measure can be found in eBG-OS-03-Quality Assurance Plan.doc

COPYRIGHT © 2005 INTEL CORPORATION. ALL RIGHTS RESERVED.

Project Planning eBG-PD-22-003
Schedule Management Process April 28, 2005
Page 11 OF 11

Schedule Variance can be found in eBG-OS-03-Quality Assurance Plan.doc

Cost Variance can be found in eBG-OS-03-Quality Assurance Plan.doc

5.0 Process References:

The eBG Organizational Standard Process: eBG-OS-01-Organizational Standard Process.doc

The eBG Configuration Management Plan: eBG-OS-02-Configuration Management Plan.doc
The eBG Quality Assurance Plan: eBG-OS-03-Quality Assurance Plan.doc
The eBG Project Management Plan Template: eBG-TP-20-Project Management Plan.doc
The eBG Resource Allocation Process: eBG-PD-31-Resource Allocation.doc

COPYRIGHT © 2005 INTEL CORPORATION. ALL RIGHTS RESERVED.