Download Project Management Plan

Project Management Plan
Overview
Date
Contents

The Project Management Framework – Review
Project Plan
Project Charter
Business Case Development
Requirements
Project Plan Initial Schedule Template
Change Control
Project Tracking
Performance Reporting
Estimating
Risk Management
Quality Management
Communications

PMO Integration















Organization
Roles and Responsibilities
Rules of Engagement
-2-
Project Management Framework - Review
Project
Management
Processes
Project
Objectives
Project
Phases
Plan
Time
Concept
Schedule
Cost
Definition
Control
Performance
Design
Development
Deployment
Post-completion
Project management processes are the things Project Managers do
to control project objectives in each project phase.
-3-
Project Plan Terms

Project Plan
A formal, approved document 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. A project plan may be summarized or detailed.

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).

Four parts to a Project Plan:




Refined descriptions of goals, objectives, performance criteria, and technical impacts (see
Project Charter template tab and page)
Completed requirements document (see Requirements sample table of contents and
checklist tab and page)
Refined Business Case (see Business Case template tab and page)
Refined Schedule (see Initial Schedule template tab and page)
-4-
Project Charter Defined

Project Charter
A document which defines the project in three parts:
(1) A clear and thorough written description of the project scope that
includes goals, objectives, performance criteria, and technology
impacts;
(2) A business case that establishes baseline metrics against which
project results can be measured (includes a quantitative cost/benefit
analysis as well as qualitative baselines); and
(3) A written statement by senior management that provides the
project manager with the authority to apply organizational resources
to project activities.
-5-
Concept Phase = Project Charter Development
1. Project Scope




Goals and objectives
Performance criteria
Technology impact
If a feasibility study, includes marketing inputs
2. Business Case



Establishment of quantified baselines through cost/benefit analysis
Establishment of qualitative baselines
If a feasibility study, includes competitive analysis
3. Authorization



Presentation of case
Authorization decision made and obtained
Communication of decision to organization
Major Outcome: APPROVAL
-6-
How to Develop the Business Case

Complete first draft of the project business case template

Complete first draft of the project financial model template

Review assumptions in first draft of both templates with Financial
Planning and adjust as necessary


Review for process considerations (whether requisite fields are filled out correctly)
Review for content (consult with Financial Planning on rationales and numbers)

Review adjusted draft with Project Sponsor

Iterate between Financial Planning and Sponsor until satisfied

Finalize project business case and financial model templates and move
to Authorization steps
-7-
Definition Phase = Requirements and Outcomes

Outcome defines the “what” which is to be done

Development of a comprehensive single requirements document





Includes detailed business requirements of business users
Includes detailed technical requirements of IT
The requirements documented should be elaborated directly from the
descriptions of the goals, objectives, performance criteria, and scope
developed in the Concept Phase. If this proves difficult, it’s a good indication
that the Concept Phase descriptions need to be revisited.
This phase calls for very close collaboration between business and IT,
requiring many iterative loops between business and IT.
This phase also:




Specifies technical architecture
Specifies QA procedures
Sets up control system (WBS, time estimates and skill sets, initial schedules)
Establishes project organization
Major Outcome: REQUIREMENTS
-8-
Requirements - SAMPLE TABLE OF CONTENTS
-9-
Requirements - CHECKLIST
- 10 -
Project Schedule Terms

Work Breakdown Structure (WBS)
The WBS is 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.
Up to 20 levels can be used. At Company, we will use only these four:
Phase > Deliverable > Activity > Task
A WBS does not show the sequencing of the work to be performed. Such
sequencing is determined when a schedule is developed.
A WBS should be developed before scheduling and resource allocation
are done.
- 11 -
Deliverables Framework
Phases
Concept

Project charter



Project scope
Business
case model
 Authorization
Business/
Application

Project charter
 Current
technology
assessment
Technical

Management
Definition
Definition work
plan
 Consult IA and
Compliance
 Risk
assessment
Design


Requirements
document

High level use
case model
 Preliminary
object model
 Bus model




Process model
Detailed use
case model
Object model
Data Model
System test plan
Bus proc model
Development







Architecture
guidelines and
principles
 Architecture
definition

Technology
blueprint
 Application
frameworks
 Development
environment





Release plan
Design and
development
work plan
 Risk
assessment
- 12 -
Risk
assessment
Tested system
Sales materials
Hiring Plan
Training plan
Training material
Policies and
procedures
Coded and
integrated
software
 Test environments
 Release
environment
 Installation and
Admin. Guide
Defect analysis
report
 Deployment work
plan
 Risk assessment
 User sign-off by
Project Acceptor
Deployment


Trained users
Implemented
system
PostCompletion

Post project
report
Change Control Terms

Change Control Decision Maker
The Project Acceptor is accountable for approving or rejecting changes requested
to the project baselines. There will be no need for a formal Change Control Board
at Company.

Change Control Form
A formal document used to request a change in scope of time, cost, and/or
performance. Any member of the project team, including the Sponsor, can initiate
a change request. The Project Managers (business and IT) must concur with the
requested change before it is formally logged. Once approved by the PMs, the
change is recorded on the Change Control Log. The Project Acceptor must
approve the change before it can take effect. If so approved, changes are
recorded as additions in scope to the Project Plan and baselines.

Change Control Log
Maintained by the IT Project Manager (or IT Project Director if there is one) to log
and document additions in scope to the Project Plan and baselines.
- 13 -
Authorization and Change Control Through The
Project Phases
Project
Charter
Phased Authorization
(As Required)
Requirements
Charter
Authorization
Project Plan
> Initial Schedule
> Refined Bus Case
> Refined Scope
> Requirements
Specifications
DEV
SYS
TEST
Project
Authorization
UAT
Concept
Definition
Design
- 14 -
Development
Deployment
Post-Completion
Change Control - PROCEDURE
- 15 -
Change Control Log - TEMPLATE and EXAMPLE
- 16 -
Change Control - TEMPLATE and EXAMPLE
- 17 -
Tracking

Status Reports

Status Reporting roll-ups
- 18 -
Project Tracking: Why Track

To understand progress and determine if adjustments are necessary

To surface issues and support fact-based decision making
 To measure overall effectiveness against the projects goals for scope and
quality
 To determine the effectiveness of Risk Mitigation plans
 To increase knowledge of actual experience to be used as input for
estimating future (similar) projects
Predicting the future is easy. It’s trying to figure out what’s going
on now that’s hard.
- Fritz R. S. Dressler
- 19 -
Project Tracking: What to Track

Status

Scope
Schedule
Cost
Performance
Risk Mitigation Effectiveness




Anything that is to be tracked requires a baseline from which to do
comparison. Effective tracking cannot be done prior to a baseline being
established
- 20 -
Project Tracking: How to Track

Status





Scope



Tasks scheduled for completion and completed
Tasks scheduled for completion and not completed
Completed tasks not scheduled
Issues
by Project size
with Change Control Logs, Documents, and Metrics
Schedule


by Milestones - actual versus plan
by capacity analysis
- 21 -
Project Tracking: How to Track (Continued)

Cost



Performance



by Effort - actual versus plan
by $ expenditures - actual versus plan
by Software defect metrics
by Financial metrics (e.g., ROI, IRR, NPV)
Risk Mitigation Effectiveness


by Risk Event Status over time (individual and aggregated)
by Contingency utilization
- 22 -
Project Tracking: Frequency
Tracking Component
Status
Weekly
Monthly


As Needed

Scope: Size
Scope: Change Control


Schedule: Milestones



Schedule: Capacity

Cost

Performance: S/ W Defects

Performance: Financial

Risk Mitigation
- 23 -
Project Tracking: Summary

Effective project tracking is essential to achieving project objectives

Baselines and success measures for all components being tracked must
be known, understood, and agreed to at project start by all key
stakeholders
- 24 -
Weekly Status Report PROCEDURE, TEMPLATE, & EXAMPLE
- 25 -
Monthly Status Report PROCEDURE, TEMPLATE, and RISK EXAMPLE
- 26 -
Weekly Issues Status Review

Status Reporting (weekly and monthly) covers the reasons for not
meeting plan dates and calls out the issues which have caused project
tasks to be late

However, issues are not worked for resolution in status review meetings

Issues are managed and resolved through a separate Issues Status
Report which becomes the basis for a weekly Issues Status Review
Meeting
- 27 -
Weekly Issues Status Review PROCEDURE, TEMPLATE, & EXAMPLE
- 28 -
Estimating Techniques

Preliminary Estimating




Based on External Count
Based on Coding Estimates
Based on Object-oriented Analysis, Design, and Development
Contingency Estimating
- 29 -
Preliminary Estimating: Externals

Estimating models based on #




Screens (and dialogues)
Reports (and notices)
External System Interfaces
Total counts are extended by an average number of days per external
based on historical information (and allocated based on historical
percentages)
- 30 -
Preliminary Estimating: Coding

Estimating models based on # and complexity ranking modules

Complexity provides a range of effort



Small = 1 - 3 days
Medium = 3 - 5 days
Complex = 8 - 10 days

Total “code and unit test” is calculated by multiplying

Remaining estimates are allocated in relation to the overall percentage of
“code and unit test” based on historical information
- 31 -
Preliminary Estimating: OO

Estimating models based on #, complexity ranking, # of iterations, and
iteration multiplier for:






Use Cases
Use Interfaces
Dataviews
Domain Objects
Object Model-to-Data View interactions
User Interface-to-Data Model interaction
- 32 -
Contingency Estimating

Based on a high, medium, low assessment of key factors:





Confidence regarding unknowns
Team experience with project technology
Team experience with business (e.g., PDA knew nothing about the flood business before
they got involved)
Team experience with project methodology
Team experience working together
- 33 -
Estimating - PROCESS and TEMPLATE
- 34 -
Estimating - USE CASE GUIDELINES
- 35 -
Risk Management - Basic Terms

Project Risk Management
A subset of project management that includes the processes concerned with identifying,
analyzing, and responding to project risk. It consists of risk identification, risk
quantification, risk response development, and risk response control.

Risk Identification
Determining which risk events (discrete occurrences that may affect the project for
better or worse) are likely to affect the project.

Risk Quantification
Evaluating the probability of risk event occurrence and effect (impact). We often call
this “Risk Assessment”.

Risk Response Development
Defining enhancement steps for opportunities and mitigation steps for threats. We
often call this “Risk Mitigation”.

Risk Response Control
Responding to changes in risk over the course of the project.
- 36 -
Project Risk Management
Project risk is the cumulative effect of the chances of
uncertainty adversely affecting project objectives.
- 37 -
Risk Management: Definitions

Risk Event
Precisely what might happen to the detriment of the project

Risk Probability
How likely is the event to occur

Amount at Stake
The severity of the consequences if the event occurs

Risk Event Status
Equals “Risk Probability” times “Amount at Stake”
Risk Event, Risk Probability, and Amount at Stake are the three
risk factors used to characterize all risks.
- 38 -
Risk Management: Risk Identification

Three types of Risk
Knowns, Known-unknowns, and Unknown-unknowns

Two kinds of Risk Events
Discrete and Continuous

Five “source” categories
External Unpredictable, External Predictable, Internal Non-technical, Technical, Legal

Eight methods to identify
Brainstorming, Sensitivity Analysis, Probability Analysis, Delphi Method, Monte Carlo,
Decision Tree Analysis, Utility Theory, Decision Theory
- 39 -
Risk Assessment
Five step process
1. Select the risk events to be examined.
High
2. Assess the probability and timeframe
associated with the event(s).
High
Risk
3. Assess the consequences and severity of
the events.
4. Develop mitigation plans to reduce the
probability and/or the impact of the
event(s).
Probability

Low
Risk
5. Accumulate the assessment results into a
“Conclusions and Recommendations”
document.
Low
- 40 -
Severity
High
Risk Management: Risk Response

Response options:








Ignore
Recognize but take no action
Avoid (by taking appropriate steps)
Reduce (by taking an alternative approach)
Share (by joint venture)
Transfer (by contract or insurance)
Retain and absorb (by contingency allowances)
Three mitigation components



Standards
Insurance
Planning Alternatives
- 41 -
Risk Management: Documentation

Project Risk Profiling

Project Risk Database

Historical Risk Database
Structured post-project reviews are a key best
practice to ensure historical risk information is
captured and available as input to future projects.
- 42 -
Risk Management: Summary

Risk Management is an essential component of Project
Management that is required for all projects

A standard Project Risk Management methodology will provide
consistency in identifying, assessing, mitigating, and reporting risk
events across all projects and programs

Corporate and individual Project Risk Management skills and
methods will evolve and improve over time

Project Risk Management is an on-going process through all
phases of the project’s life cycle
- 43 -
Risk Management - PROCESS and TEMPLATES
- 44 -
Quality Management - Basic Terms

Project Quality Management
A subset of project management that includes the processes required to
ensure that the project will satisfy the needs for which it was undertaken. It
consists of quality planning, quality assurance, and quality control.

Quality Planning
Identifying which quality standards are relevant to the project and determining how to
satisfy them.

Quality Assurance (QA - planning and taking proactive measures)
(1) The process of evaluating overall project performance on a regular basis to provide
confidence that the project will satisfy the relevant quality standards. (2) The
organizational unit that is assigned responsibility for quality assurance.

Quality Control (QC - measuring)
(1) The process of monitoring specific project results to determine if they comply with
relevant quality standards and identifying ways to eliminate causes of unsatisfactory
performance. (2) The organizational unit that is assigned responsibility for quality
control.
- 45 -
Quality Management - PROCESS and TEMPLATES
- 46 -
Communications

Via Weekly and Monthly Status Reports to team and to PMO
audiences

Coordinate with Communications Department for routine periodic
updating to organization to keep project in the public eye
- 47 -
Enterprise Program Management Office
Vision Statement
“We empower the people of Company to identify and create new
ways of conducting business. To fuel growth we encourage new,
innovative uses of business and information technologies. To
manage this growth, we are deploying throughout Company
standard program and project management processes. These
processes enable us to manage risk, determine cost and benefit,
and assure the strategic alignment of all initiatives with the
corporate goals and objectives.”
- 48 -
Governance and Structure
Inter-Organizational Alignment of Strategic Business Initiatives & IT Projects
Operating Committee
Enterprise Program
Management Office
Business Units
Information Technology
Strategic Business
Initiatives Sponsor/Owner
IT Program
Management Office
IT Project 1
eBusiness
Integrated
Product
Integrated
Benefits
IT Project 2
IT Project 3
IT Project N
Bank & Agent
Consolidation
- 49 -
Governance and Structure
IT Internal Coordination Crosses all IT Organizational Boundaries
Operating Committee
Enterprise Program
Management Office
Information Technology
Business Units
IT Program
Management Office
Strategic Business
Initiatives Sponsor/Owner
Operations
Infrastructure
Application
Development
IT Project 1
eBusiness
Integrated
Product
Integrated
Benefits
IT Project 2
IT Project 3
IT Project N
Bank & Agent
Consolidation
- 50 -
Special
Projects
Governance and Structure
Business Unit Provides Justification and Alignment
Operating Committee
Enterprise Program
Management Office
Information Technology
Business Units
Strategic Business
Initiatives Sponsor/Owner
Business
Business Case
IT Program
Management Office
Operations
Infrastructure
Results
Strategic
Alignment
Application
Development
IT Project 1
eBusiness
Integrated
Product
IT Project 2
IT Project 3
Integrated
Benefits
IT Project N
Bank & Agent
Consolidation
- 51 -
Special
Projects
Governance and Structure
Operating Committee and the PMO
Operating Committee
•Make Decisions
•Provide Direction
•Ensure Alignment
•Allocate Resources
•Ensure Success
Enterprise Program
Management Office
•Report Results
Information Technology
Business Units
IT Program
Management Office
Strategic Business
Initiatives Sponsor/Owner
Business
Business Case
Operations
Infrastructure
Results
Strategic
Alignment
Application
Development
IT Project 1
eBusiness
Integrated
Product
IT Project 2
IT Project 3
Integrated
Benefits
IT Project N
Bank & Agent
Consolidation
- 52 -
Special
Projects
Roles and Responsibilities
Program Management Office (PMO)
General
• Align strategic business initiatives with overall corporate vision
• Ensure successful implementation of strategic business initiatives
• Provide direction, guidance, and timely decision making
• Review recommendations and resolve conflicts among competing and
conflicting initiatives and resources
• Provide recommendations to adapt and refocus the business in response
to changing marketplace and business changes
• Schedule meetings at regular intervals
• Conduct meetings based on published agendas
• Communicate regularly with stakeholders on progress and success of
strategic business initiatives
• Drive decision-making process through fact-based analysis and
commitment to measurable performance criteria
- 53 -
Roles and Responsibilities (Continued)
Program Management Office (PMO)
Specific
• Employ consistently project management methodologies, processes and
tools
• Define business case development, planning, tracking, risk assessment
and reporting standards and tools
• Provide mentoring and training for Project Managers
• Assist with Business Case development, Risk Assessments, Estimating
and Planning, and Project Reviews
•
•
•
Prepare Enterprise Risk Profile Reports
Establish and maintain Project Management metrics database
A full time PMO administrator is recommended
- 54 -
Roles and Responsibilities
IT Program Management Office (ITPMO)
General
• Ensure IT portfolio (infrastructure, platforms, applications, tools and
human capital) resources are aligned to support strategic business
priorities
• Employ consistently project management methodologies, processes and
tools
• Provide recommendations to adapt and refocus the IT portfolio in
response to changing IT and business changes
• Provide direction, guidance, and timely decision-making on IT solutions
• Review recommendations and resolve conflicts among competing and
conflicting initiatives and resources
• Communicate regularly with stakeholders on progress and success of IT
solutions
• Drive decision-making process through fact-based analysis and
commitment to measurable performance criteria
- 55 -
Roles and Responsibilities (Continued)
IT Project Management Office (ITPMO)
Specific
• The CIO will chair the ITPMO
• Employ consistently project management methodologies, processes and
tools
• Deploy standard life cycle methodology and planning, tracking, risk
assessment and reporting standards and tools
• Provide mentoring and training for IT Project Managers
• Assist with Business Case development, Risk Assessments, Estimating
and Planning, and Project Reviews
• Prepare IT Risk Profile Reports
• Establish and maintain IT Project Management metrics database
- 56 -
Rules of Engagement (PMO and ITPMO)
Collaboratively Achieving Success
•
Active participation of all team members
•
Encourage debate and discussion
Challenge all assumptions
Acknowledge expertise
Facts drive decisions, not emotions
Consensus is the goal; however, decision making must be timely
•
•
•
•
•
Decisions will not be second-guessed, but may be revised by the
entire PMO based on compelling business or information technology
changes
• Prepare, distribute, and review agenda and all material prior to
meetings
•
Stick to the agenda
• Timebox all discussions and stay within the time contact
• Post-meeting distribution of the “Final Document” will be in lieu of
minutes and will be the responsibility of the PMO administrator
- 57 -
Operating and IT Steering Committee and PMO
Current, Transition and Future Operating Environment
Current
• Operating Committee membership provides core of Interim Program Management Team
(IPMT)
• Additional IPMT membership represents both business and IT
• IPMT membership should remain the same through August, 2000
Transition and Future
• Formal PMO should be composed of second level business and IT managers
• Membership should rotate every 18 to 24 months
• Positions are part-time, with meetings scheduled bi-monthly for first six months, then monthly
thereafter
• Additional (full or part-time) staff required includes a financial analyst (recommended)
Future ITPMO
• IT Steering Committee will be eliminated and replaced by the PMO
• Within IT a newly formed group, IT Program Management Office (ITPMO) will manage IT
internal program management activities and will be chaired by the CIO
• ITPMO will report to the PMO and thus is subordinate to PMO decisions, vision, and direction
• Membership should be composed of mixture of senior and second level IT managers
• Membership should rotate every 18 to 24 months
• Positions are part-time with meetings scheduled bi-monthly
- 58 -