Escolar Documentos
Profissional Documentos
Cultura Documentos
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).
3.1
Establish
Project 3.6
Timeline Schedule
Schedule Change
Management and
Control
1
3.0 Process Steps
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.
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.
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
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.
Purpose Activity sequencing is the process of placing project activities in a logical, sequential order.
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.
Purpos Activity estimating is the process of analyzing the project activities and assigning estimates to the activities to
e feed into schedule development.
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.
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:
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.
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.
4.0 Measures