Sie sind auf Seite 1von 1831

OUM 6.

2Full Method View


Method Navigation Current Page Navigation
VIEW DESCRIPTION AND KEY COMPONENTS
Description
The Full Method view provides access to all the material associated with OUM including supplemental content and reference files.
Key Components
Full Method:
Method Overview
Activities and Task WBS View
Supplemental Guidance:
Supplemental Guidance
Method Resources:
OUM Project Workplan
Key Work Products
OUM Mapping Documents
DIAGRAM NAVIGATION
This section contains a navigation diagram with links. Place your cursor over the area of interest in the diagram and click.
MANAGE FOCUS AREA - GUIDELINES
This section contains links to Phase Overviews, Process Overviews, Activity Overviews, and References.
Phase Overviews Activity Overviews References
[PS] Project Start Up
[PEC] Project Execution and Control
[PC] Project Closure
Project Start Up
Manage Focus Area Overview
Project Roles
Definitions/Terms
Miscellaneous Templates
Planning a Project using OUM
Review Bid and Contract
Review Project Assets with Client
Validate Scope, Stakeholders and OCM Strategy
Develop Workplan
Develop Staff Plan and Budget
Complete Project Management Plan
Establish Project Infrastructure
Tailoring OUM for Your Project
Managing an OUM Project using Scrum
Scrum to OUM Mapping
Manage Key Concepts
Project Management in OUM
Tips for Project Managers
Manage Activities and Tasks View
Manage Project Workplan (MPP)
Program Management in OUM
Workshop Techniques Handbook
Process Overviews Project Execution and Control
[BT] Bid Transition
[SM] Scope Management
[FM] Financial Management
[WM] Work Management
[RKM] Risk Management
[IPM] Issue and Problem Management
[STM] Staff Management
[CMM] Communication Management
[QM] Quality Management
[CM] Configuration Management
[IFM] Infrastructure Management
[PCM] Procurement Management
[OCHM] Organizational Change Management
Manage Scope, Acceptance and Approvals
Manage Project Finances
Manage Project Workplan
Manage Risks, Issues and Problems
Orient and Manage Team
Manage Communications and OCM Plans
Manage Project Quality
Create and Execute Configuration and Release Management
Manage and Maintain Infrastructure
Administer Procurement of Goods and Contracted Services
Project Closure
Gain Acceptance
Close Processes and Contract
Document Lessons Learned and Archive Project
ENVISION FOCUS AREA - GUIDELINES
This section contains links to Phase Overviews, Process Overviews and References. The links in the Process Overviews column take you to the Process Overview
pages. The links in the Tasks and Work Products column take you to the Envision Focus Area - Tasks and Work Products tables further down this page.
Phase Overviews Process Overviews Tasks and Work Products References
[INIT] Initiate
[ME] Maintain and Evolve
[ER] Envision Roadmap
[BA] Enterprise Business Analysis
[OCM] Organizational Change
Management
[EA] Enterprise Architecture
[IP] IT Portfolio Management
[GV] Governance
[ER] Envision Roadmap
[BA] Enterprise Business Analysis
[EOCM] Organizational Change
Management
[EA] Enterprise Architecture
[IP] IT Portfolio Management
[GV] Governance
Envision Focus Area Overview
TOGAF Overview
ESF Overview
Envision Touch Points
Project Roles
Definitions/Terms
Envision Activities and Task WBS View
For Project Managers and Planners:
Envision Work Breakdown Structure
Envision Project Workplan (MPP)
IMPLEMENT FOCUS AREA - GUIDELINES
This section contains links to Phase Overviews, Process Overviews and References. The links in the Process Overviews column take you to the Process Overview
pages. The links in the Tasks and Work Products column take you to the Implement Focus Area - Tasks and Work Products tables further down this page.
Phase Overviews Process Overviews Tasks and Work Products References
[A] Inception
[B] Elaboration
[C] Construction
[D] Transition
[E] Production
[RD] Business Requirements
[RA] Requirements Analysis
[MC] Mapping and Configuration
[AN] Analysis
[DS] Design
[IM] Implementation
[TE] Testing
[PT] Performance Management [TA]
Technical Architecture
[CV] Data Acquisition and Conversion
[DO] Documentation
[OCM] Organizational Change
Management
[TR] Training
[TS] Transition
[PS] Operations and Support
[RD] Business Requirements
[RA] Requirements Analysis
[MC] Mapping and Configuration
[AN] Analysis
[DS] Design
[IM] Implementation
[TE] Testing
[PT] Performance Management
[TA] Technical Architecture
[CV] Data Acquisition and Conversion
[DO] Documentation
[OCM] Organizational Change
Management
[TR] Training
[TS] Transition
[PS] Operations and Support
Implement Focus Area Overview
Envision Touch Points
Project Roles
Definition/Terms
Blended Delivery
Implement Activities and Task WBS View
Implement Work Breakdown Structure (HTML)
Back to Top
MANAGE FOCUS AREA - TASKS AND WORK PRODUCTS
expand all | collapse all
[PS] Project Start Up
Phase Task Overview Work Product Template
Review Bid and Contract
PS BT.010 Review and Analyze Bid Material Reviewed and Analyzed Bid Management Reviewed and Analyzed Bid Material
PS BT.020 Review and Confirm Business Case Confirmed Business Case Confirmed Business Case
PS BT.030 Identify Project Stakeholders Identified Project Stakeholders Identified Project Stakeholders
PS BT.040 Review and Accept Project Budget Accepted Project Budget Refer to the Task Overview for guidance.
PS RKM.020 Conduct Baseline Risk Assessment Baseline Risk Assessment Baseline Risk Assessment
Risk Mitigation
Review Project Assets with Client
PS BT.050 Review Contract with Client Reviewed Contract Reviewed Contract
PS BT.060 Review Project Approach with Client Reviewed Project Approach Reviewed Project Approach
PS BT.070 Create Project Management Framework Project Management Framework Project Management Framework-Word
Abbreviated Project Management Framework-
PowerPoint
Validate Scope, Stakeholders and OCM Strategy
PS SM.010 Define and Confirm Scope Validated Scope Validated Scope
PS CMM.010 Conduct Project Stakeholder Analysis Project Stakeholder Analysis Project Stakeholder Analysis
PS OCHM.010 Understand Client's Organizational
Change Management Strategy
Client's Organizational Change Management
Strategy
Client's Organizational Change Management
Strategy
Develop Workplan
PS WM.010 Develop Baseline Project Workplan Baseline Project Workplan Implementation Plan
Iteration Plan Summary
OUM Project Workplan
Develop Staff Plan and Budget
PS FM.010 Refine Project Budget Approved Project Budget Refer to the Task Overview for guidance.
PS STM.010 Plan Resource Requirements Resource Plan Project Team Organization Chart
Resource Plan
PS STM.030 Staff Project Staffed Project Refer to the Task Overview for guidance.
PS STM.040 Prepare Orientation Guide Orientation Guide Project Orientation Guide
Complete Project Management Plan
PS SM.020 Develop Scope Change Management
Processes
Scope Change Management Processes Scope Change Management Process
Scope Change Management Checklist
PS FM.020 Develop Financial Management Plan Financial Management Plan Financial Management Plan
PS WM.020 Develop Work Management Execution
and Control Processes and Policies
Work Management Plan Work Management Execution and Process and
Policies
PS RKM.010 Develop Risk Management Plan Risk Management Plan Risk Management Plan
PS IPM.010 Develop Issue Management Strategy Issue Management Strategy Issue Management Strategy
PS IPM.020 Develop Problem Management Strategy Problem Management Strategy Problem Management Strategy
PS STM.020 Develop Staff Management Plan Staff Management Plan Staff Management Plan
Staff Training Plan
Staff Management Procedures
Project Roles and Responsibilities Presentation
PS CMM.020 Develop Project Team Communication
Plan
Project Team Communication Plan Project Team Communication Plan
Client Profile
Steering Committee Presentation
PS QM.010 Develop Quality Management Plan Quality Management Plan Quality Management Plan
Quality Management Procedures (Generic)
Quality Management Procedures (Modified for
OUM)
PS QM.020 Develop and Document Quality Control
and Reporting Process
Quality Control and Reporting Process Quality Control and Reporting Process
Quality Control Checklist
Quality Review Report (Generic)
Quality Review Report (Modified for OUM)
PS CM.010 Develop Configuration Management
Strategy and Processes
Configuration Management Plan and Processes Configuration Management Plan and Processes
Configuration Management Procedures
Configuration Item Index
Configuration Item Status Record
PS CM.030 Create Project Documentation
Management Plan
Documentation Management Plan Documentation Management Plan
Document Index-Word
Document Index-Excel
Document Update Notice
PS IFM.010 Develop Infrastructure Management
Plan
Infrastructure Management Plan Infrastructure Management Plan
Installation Plan and Record
PS PCM.010 Develop Procurement Strategy and
Process
Procurement Strategy and Process Procurement Strategy and Process
PS OCHM.020 Identify Change Management
Warning Signs
Change Management Warning Signs Change Management Warning Signs
Establish Project Infrastructure
PS FM.030 Set Up Time and Expense Tracking Time and Expense Tracking Expense Tracking Spreadsheet
Project Team Time Sheet
PS RKM.030 Develop Risk Management System Risk Management System Risk Form
Risk Log
Risk/Issue/Problem Log
PS IPM.030 Develop Issue and Problem
Management System
Issue and Problem Management System Issue Form
Issue Log
Problem Form
Problem Log
Risk/Issue/Problem Log
PS CM.020 Obtain Configuration Management Tools Configuration Management Tools Refer to the Task Overview for guidance.
PS IFM.020 Establish Team Work Environment Team Work Environment Refer to the Task Overview for guidance.
PS IFM.030 Establish Technical Infrastructure Established Technical Infrastructure Physical Resource Plan
PS PCM.020 Procure Goods and Contracted
Services
Service Orders Refer to the Task Overview for guidance.
Back to Top
[PEC] Project Execution and Control
Phase Task Overview Work Product Template
Manage Scope, Acceptance and Approvals
PEC SM.030 Manage Scope Managed Scope Change Request Form
Change Request Log
PEC SM.040 Manage Acceptance Managed Acceptance Acceptance Criteria
Acceptance Certificate
PEC WM.050 Manage Approvals Managed Approvals Refer to the Task Overview for guidance.
Manage Project Finances
PEC FM.040 Manage Project Finances Managed Project Finances Refer to the Task Overview for guidance.
Manage Project Workplan
PEC WM.030 Manage Project Workplan Project Workplan Assignment Request
Deliverable Tracking Spreadsheet
Unplanned Activity Log
Iteration End Report
PEC WM.040 Track Schedule Performance Schedule Performance Refer to the Task Overview for guidance.
Manage Risks, Issues and Problems
PEC RKM.040 Manage Risk Managed Risk Refer to the Task Overview for guidance.
PEC RKM.050 Monitor and Control Risk Assessed Risk Monitor and Control Risk
PEC IPM.040 Manage Issues and Problems Managed Issues and Problems Refer to the Task Overview for guidance.
Orient and Manage Team
PEC QM.030 Conduct Project Team Quality
Management Orientation
Project Team Quality Management Orientation Project Team Quality Management Orientation
Presentation
PEC STM.050 Conduct Team Orientation Oriented Team Project Kickoff Presentation
PEC STM.060 Manage Project Team Managed Project Team Individual Status Report
Assignment Request
Assignment Terms of Reference
Manage Communication and OCM Plans
PEC CMM.030 Manage Project Team Communication Project Team Communication Meeting Minutes
Weekly Project Status Report with Instructions
Weekly Project Status Report
PEC OCHM.030 Execute Change and Communication
Plan
Executed Change and Communication Plan Refer to the Task Overview for guidance.
Manage Project Quality
PEC QM.040 Manage Quality Control Quality Control Review Comments List
Review Leader Form
PEC QM.050 Perform Quality Assurance Managed Quality Assurance Audit Action Report
Audit Report
Quality Report
Create and Execute Configuration and Release Management
PEC CM.040 Create and Execute Software
Configuration Management Plan
Software Configuration Management Plan Software Configuration Management Plan
PEC CM.050 Create and Execute Software Release
Management Plan
Software Release Management Plan Software Release Management Plan
Release Note
PEC CM.060 Create and Execute Environment and
Patch Management Plan
Environment and Patch Management Plan Environment and Patch Management Plan
PEC CM.070 Create and Execute Configuration Control
Plan
Configuration Management Control Plan Configuration Management Control Plan
Manage and Maintain Infrastructure
PEC IFM.040 Manage and Maintain Infrastructure Maintained Infrastructure Equipment Fault Record
Administer Procurement of Goods and Contracted Services
PEC PCM.030 Administer Procurement of Goods and
Contracted Services
Managed Procurement of Goods and Services Incoming Item Record
Rejection Note
Back to Top
[PC] Project Closure
Phase Task Overview Work Product Template
Gain Acceptance
PC SM.050 Gain Acceptance Final Acceptance Certificate Acceptance Certificate
Project Acceptance Report
Close Processes and Contract
PC SM.060 Close Scope Management Closed Scope Management Scope Management Lessons Learned
PC SM.070 Identify Future System Enhancements Future System Enhancements Future System Enhancements
PC FM.050 Close Project Financials Closed Project Financials Financial Management Lessons Learned
PC WM.060 Close Work Management Closed Work Management Work Management Lessons Learned
PC RKM.060 Conduct Post-Production Risk
Assessment
Post-Production Risk Assessment Post-Production Risk Assessment
Risk Assessment Lessons Learned
PC IPM.050 Product Final Issue and Problem Report
and Close Log(s)
Closed Issue and Problem Log Issue and Problem Management Lessons Learned
PC STM.070 Release Staff Released Staff Released Staff
PC CMM.060 Submit Final Reports Final Reports Project Closure
End Report
Engagement Summary
PC QM.060 Conduct Post-Production Quality Review Post-Production Quality Review Client Satisfaction Report
Project Healthcheck Checklist
Metrics Report
PC CM.080 Close Configuration Management Closed Configuration Management Configuration Management Lessons Learned
PC IFM.050 Close Infrastructure Closed Infrastructure Closed Infrastructure
PC PCM.040 Close Contract Closed Contract Supplier Assessment Record
PC OCHM.040 Establish Follow-Up Process Follow-Up Process Follow-Up Process
Document Lessons Learned and Archive Project
PC CMM.040 Document Lessons Learned Lessons Learned Lessons Learned
PC CMM.050 Turn Over Project Documentation Lessons Learned Project Archives
Back to Top
ENVISION FOCUS AREA - TASKS AND WORK PRODUCTS
expand all | collapse all
[ER] Envision Roadmap
Phase Task Overview Work Product Template
Initiate Phase
INIT ER.010 Create Business Case for Envision
Engagement
Customer Envision Engagement Strategy Refer to the Task Overview for guidance.
INIT ER.015 Conduct Enterprise Maturity Assessment Maturity Analysis and Recommendations Report Refer to the Task Overview for guidance.
INIT ER.020 Determine Envision Engagement Strategy Envision Engagement Strategy Envision Engagement Strategy
INIT ER.025 Educate Enterprise on Area of Focus Educated Enterprise Area of Focus Foundation
INIT ER.030 Set and Agree on Plan for Envision
Engagement
Envision Engagement Plan Envision Engagement Plan
INIT ER.040 Research Enterprise Enterprise Research Findings Enterprise Research Findings
INIT ER.045 Establish Executive Sponsorship Committed Executive Sponsorship Refer to the Task Overview for guidance.
INIT ER.050 Validate and Agree on Envision
Engagement Plan
Agreed on Envision Engagement Plan Refer to the Task Overview for guidance.
INIT ER.070 Define Modeling Strategy for the
Enterprise
Enterprise Modeling Strategy Refer to the Task Overview for guidance.
INIT ER.080 Obtain Existing Reference Material Existing Reference Material Refer to the Task Overview for guidance.
INIT ER.090 Conduct Solution Readiness Assessment Solution Readiness Assessment Solution Readiness Assessment
INIT ER.100 Define Supplemental Enterprise
Requirements
Supplemental Enterprise Requirements Refer to the Task Overview for guidance.
INIT ER.110.1 Perform Benefit Analysis Benefit Analysis Benefit Analysis
INIT ER.110.2 Perform Benefit Analysis Benefit Analysis Benefit Analysis
INIT ER.120.1 Identify and Mitigate Future State Risks Future State Risks Future State Risks
INIT ER.130.1 Produce MoSCoW Improvement List MoSCoW Improvement List MoSCoW Improvement List
INIT ER.140 Share Product Strategies with Enterprise Informed Enterprise Refer to the Task Overview for guidance.
INIT ER.150 Review Discovery Findings Reviewed Discovery Findings Refer to the Task Overview for guidance.
INIT ER.160 Develop Desired Future State Desired Future State Refer to the Task Overview for guidance.
INIT ER.165 Identify Capability Challenges Capability Challenges Refer to the Task Overview for guidance.
INIT ER.167 Determine Remediation Approaches Remediation Approaches Refer to the Task Overview for guidance.
INIT ER.170 Develop Future State Transition Plan Future State Transition Plan Future State Transition Plan
INIT ER.180 Prepare for and Present Solution
Recommendation
Solution Recommendations Refer to the Task Overview for guidance.
INIT ER.190 Review Business Feedback and Identify
Opportunities
Opportunities Task List Opportunities Task List
INIT ER.200 Prepare for Transition to Sales or Services Opportunities Action Plan Opportunities Action Plan
Maintain and Evolve Phase
ME ER.120.2 Identify and Mitigate Future State Risks Future State Risks Refer to the Task Overview for guidance.
ME ER.130.2 Produce MoSCoW Improvement List MoSCoW Improvement List Refer to the Task Overview for guidance.
ME ER.210 Monitor Current Situation and Pursue
Relevant Updates
Monitored Current Situation Refer to the Task Overview for guidance.
Back to Top
[BA] Enterprise Business Analysis
Phase Task Overview Work Product Template
Initiate Phase
INIT BA.010 Identify Business Strategy Business Strategy Business Strategy
INIT BA.012 Define Business Scope Business Scope Refer to the Task Overview for guidance.
INIT BA.015 Conduct Enterprise Stakeholder
Assessment
Enterprise Stakeholder Inventory Enterprise Stakeholder Inventory
INIT BA.017.1 Determine Metrics Collection and
Reporting Strategy
Metrics Collection and Reporting Strategy Refer to the Task Overview for guidance.
INIT BA.018.1 Establish Current Baseline Metrics Current Baseline Metrics Refer to the Task Overview for guidance.
INIT BA.020 Document Enterprise Organization
Structures
Enterprise Organization Structures Enterprise Organization Structures
INIT BA.025 Determine Operating Model Validated Operating Model Refer to the Task Overview for guidance.
INIT BA.030.1 Develop Enterprise Glossary Enterprise Glossary Enterprise Glossary
INIT BA.040 Create Enterprise Function or Process
Model
Enterprise Function or Process Model Enterprise Process Model
INIT BA.045 Develop Enterprise Business Context
Diagram
Enterprise Business Context Diagram Enterprise Business Context Diagram-PowerPoint
Enterprise Business Context Diagram-Visio
Template and Stencil
INIT BA.050 Develop Enterprise Domain Model
(Business Entities)
Enterprise Domain Model Enterprise Domain Model
INIT BA.055 Develop Enterprise Knowledge Flow Enterprise Knowledge Flow Refer to the Task Overview for guidance.
INIT BA.058 Develop Business Architecture Business Architecture Refer to the Task Overview for guidance.
INIT BA.060.1 Perform High-Level Use Case Discovery High-Level Use Cases High-Level Use Cases
INIT BA.060.2 Perform High-Level Use Case Discovery High-Level Use Cases High-Level Use Cases
INIT BA.065 Review Business-IT SLA Business-IT SLA Report Refer to the Task Overview for guidance.
INIT BA.067 Review Business Volumetrics Business Volumetrics Report Refer to the Task Overview for guidance.
INIT BA.070 Identify Candidate Services Service Portfolio - Candidate Services Service Portfolio
INIT BA.080 Identify Candidate Enterprise Business
Rules
Candidate Business Rules Refer to the Task Overview for guidance.
INIT BA.090 Identify Process Improvement Options Process Improvement Options Process Improvement Options
Maintain and Evolve Phase
ME BA.017.2 Determine Metrics Collection and
Reporting Strategy
Metrics Collection and Reporting Strategy Refer to the Task Overview for guidance.
ME BA.018.2 Establish Current Baseline Metrics Current Baseline Metrics Refer to the Task Overview for guidance.
ME BA.030.2 Develop Enterprise Glossary Enterprise Glossary Refer to the Task Overview for guidance.
ME BA.100 Maintain Enterprise Business Models Maintained Enterprise Business Models Refer to the Task Overview for guidance.
ME BA.110 Maintain Business Rules Maintained Business Rules Refer to the Task Overview for guidance.
Back to Top
[EOCM] Organizational Change Management
Phase Task Overview Work Product Template
Initiate Phase
INIT EOCM.010 Create and Manage Ad Hoc
Communications
Ad Hoc Communications Ad Hoc Communications Strategy and Approach
INIT EOCM.020 Prepare for Executive Alignment
Workshop
Executive Alignment Workshop Materials Executive Alignment Workshop Materials
Executive Alignment Workshop Presentation
INIT EOCM.030 Conduct Executive Alignment
Workshop
Executive Business Objectives and Governance
Rules
Executive Business Objectives and Governance
Rules
INIT EOCM.040 Build and Deploy Sponsorship
Program
Sponsorship Program Sponsorship Program
INIT EOCM.050 Assess Enterprise Change Readiness Preliminary Enterprise Change Readiness
Assessment
Preliminary Enterprise Change Readiness
Assessment
INIT EOCM.060 Prepare Project Team for Enterprise
Culture
Prepared Project Team Refer to the Task Overview for guidance.
INIT EOCM.070 Identify Change Agent Structure Change Agent Structure Change Agent Structure
Back to Top
[EA] Enterprise Architecture
Phase Task Overview Work Product Template
Initiate Phase
INIT EA.001 J ustify and Engage Enterprise Architects Assigned Enterprise Architect Refer to the Task Overview for guidance.
INIT EA.002 Review External Reference Architectures External Reference Architectures Review Refer to the Task Overview for guidance.
INIT EA.010.1 Review Architecture Principles,
Guidelines and Standards
Architecture Principles, Guidelines and Standards Architecture Principles, Guidelines and Standards
INIT EA.030 Identify Current Enterprise Architecture Current Enterprise Architecture Current Enterprise Architecture
INIT EA.040 Analyze Capabilities Capability Model Refer to the Task Overview for guidance.
INIT EA.050 Identify Current Architectural Challenges Current Architectural Challenges Refer to the Task Overview for guidance.
INIT EA.057 Review Business Capacity Plan Business Capacity Plan Refer to the Task Overview for guidance.
INIT EA.060 Identify Architectural Gaps and
Improvement Options
Architectural Gaps and Improvement Options Refer to the Task Overview for guidance.
INIT EA.065 Identify Enterprise IT Strategy Enterprise IT Strategy Refer to the Task Overview for guidance.
INIT EA.075 Develop Technology Reference
Architectures
Technology Reference Architectures SOA Reference Architecture
INIT EA.095 Review Enterprise Software Development
Process
Enterprise Software Development Process Refer to the Task Overview for guidance.
INIT EA.110 Develop Future State Enterprise
Architecture
Future State Enterprise Architecture Future State Enterprise Architecture
INIT EA.120 Develop Information Architecture Information Architecture Information Architecture Definitions
INIT EA.130 Develop Technology Architecture Technology Architecture Refer to the Task Overview for guidance.
INIT EA.140 Develop Applications Architecture Applications Architecture Refer to the Task Overview for guidance.
INIT EA.150 Define Transitional Architectures Transitional Architectures Refer to the Task Overview for guidance.
INIT EA.160 Define Business Rules Implementation
Strategy
Business Rules Implementation Strategy Refer to the Task Overview for guidance.
INIT EA.170 Identify Integration Requirements Integration Requirements Refer to the Task Overview for guidance.
INIT EA.190 Define Product Implementation
Prioritization
Product Implementation Prioritization Report Refer to the Task Overview for guidance.
INIT EA.200 Determine Development Framework and
Policy Guidelines
Development Framework Refer to the Task Overview for guidance.
Maintain and Evolve Phase
ME EA.010.2 Review Architecture Principles,
Guidelines and Standards
Architecture Principles, Guidelines and Standards Refer to the Task Overview for guidance.
ME EA.210 Maintain Enterprise Architectural Models Maintained Enterprise Architectural Models Refer to the Task Overview for guidance.
Back to Top
[IP] IT Portfolio Management
Phase Task Overview Work Product Template
Initiate Phase
INIT IP.010 Inventory Projects IT Project Portfolio IT Project Portfolio
INIT IP.012 Inventory Applications IT Application Portfolio IT Application Portfolio
INIT IP.014 Inventory Services Service Portfolio Service Portfolio
INIT IP.015 Conduct Portfolio Analysis Portfolio Analysis Report Refer to the Task Overview for guidance.
INIT IP.020 Analyze Services Service Portfolio - Proposed Services Service Portfolio
INIT IP.025 Populate Services Repository Populated Services Repository Refer to the Task Overview for guidance.
INIT IP.030 Analyze Business Rules Business Rules Analysis Refer to the Task Overview for guidance.
INIT IP.040 Identify Candidate Projects Candidate Projects Candidate Projects
INIT IP.050.1 Prioritize Projects Prioritized Projects Refer to the Task Overview for guidance.
INIT IP.060 Develop IT Portfolio Plan IT Portfolio Plan Refer to the Task Overview for guidance.
Maintain and Evolve Phase
ME IP.050.2 Prioritize Projects Prioritized Projects Refer to the Task Overview for guidance.
ME IP.070 Execute and Maintain IT Portfolio and
Programs>
Maintained IT Portfolio and Programs Refer to the Task Overview for guidance.
ME IP.080 Maintain Repository of Artifacts Maintained Repository of Artifacts Refer to the Task Overview for guidance.
Back to Top
[GV] Governance
Phase Task Overview Work Product Template
Initiate Phase
INIT GV.010 Define Governance Strategy Governance Strategy Governance Strategy
INIT GV.015 Review Current Governance Model Current Governance Model Refer to the Task Overview for guidance.
INIT GV.020.1 Determine Regulatory and Business
Mandates
Mandate Matrix Refer to the Task Overview for guidance.
INIT GV.030.1 Discover or Define Policies Governance Policies Catalog Refer to the Task Overview for guidance.
INIT GV.040 Determine Organizational Impact of
Governance
Impact Study and List of Proposed Organizational
Changes
Refer to the Task Overview for guidance.
INIT GV.050.1 Define Policy Implementation Processes Policy Implementation Processes Refer to the Task Overview for guidance.
INIT GV.060.1 Define Policy Implementation Tooling Governance Policy Tooling Refer to the Task Overview for guidance.
INIT GV.070.1 Define Policy Metrics Measurements Portfolio Refer to the Task Overview for guidance.
INIT GV.080.1 Define Policy Monitoring Processes Policy Monitoring Processes Refer to the Task Overview for guidance.
INIT GV.090.1 Determine Funding Model Funding Model Refer to the Task Overview for guidance.
INIT GV.092 Determine Projects Meta Data Description Projects Meta Data Description Refer to the Task Overview for guidance.
INIT GV.094 Determine Applications Meta Data
Description
Applications Meta Data Description Refer to the Task Overview for guidance.
INIT GV.096 Determine Services Meta Data
Description
Services Meta Data Description Refer to the Task Overview for guidance.
INIT GV.098 Determine Other Meta Data Descriptions Configured Enterprise Repository Refer to the Task Overview for guidance.
INIT GV.100.1 Implement Governance Governance Implementation Refer to the Task Overview for guidance.
Maintain and Evolve Phase
ME GV.020.2 Determine Regulatory and Business
Mandates
Mandate Matrix Refer to the Task Overview for guidance.
ME GV.030.2 Discover or Define Policies Governance Policies Catalog Refer to the Task Overview for guidance.
ME GV.050.2 Define Policy Implementation Processes Policy Implementation Processes Refer to the Task Overview for guidance.
ME GV.060.2 Define Policy Implementation Tooling Governance Policy Tooling Refer to the Task Overview for guidance.
ME GV.070.2 Define Policy Metrics Measurements Portfolio Refer to the Task Overview for guidance.
ME GV.080.2 Define Policy Monitoring Processes Policy Monitoring Processes Refer to the Task Overview for guidance.
ME GV.090.2 Determine Funding Model Funding Model Refer to the Task Overview for guidance.
ME GV.100.2 Implement Governance Governance Implementation Refer to the Task Overview for guidance.
ME GV.110 Monitor and Analyze Governance
Processes
Governance Implementation Improvement
Proposal
Refer to the Task Overview for guidance.
Back to Top
IMPLEMENT FOCUS AREA - TASKS AND WORK PRODUCTS
expand all | collapse all
[RD] Business Requirements
Phase Task Overview Work Product Template
Inception Phase
A RD.001 Detail Business and System Objectives Business and System Objectives Business and System Objectives
A RD.003 Identify Viewpoints Viewpoint List Refer to the Task Overview for guidance.
A RD.005 Create System Context Diagram System Context Diagram System Context Diagram-PowerPoint
System Context Diagram-Visio Template and
Stencil
A RD.011.1 Develop Future Process Model Future Process Model Future Process Model-Word
Future Process Model-PowerPoint
A RD.012 Document Present and Future
Organization Structures
Present and Future Organization Structures Present and Future Organization Structures
A RD.015 Determine KPI Collection and Reporting
Strategy
Key Business Strategies and Objectives Key Business Strategies and Objectives
A RD.020 Obtain High-Level Business Descriptions High-Level Business Descriptions High-Level Business Descriptions
A RD.030 Develop Current Business Process Model Current Process Model Current Process Model
A RD.034 Document Current Business Baseline
Metrics
Current Business Baseline Metrics Current Business Baseline Metrics
A RD.042.1 Develop Glossary Glossary Glossary
A RD.045.1 Prioritize Requirements (MoSCoW) MoSCoW List MoSCoW List-Excel
MoSCoW List-Word
Generic Workshop Notes
Generic Workshop Schedule and Workshop
Preparation Notes
A RD.055 Detail Supplemental Requirements Supplemental Requirements Refer to the Task Overview for guidance.
A RD.065 Develop Domain Model (Business
Entities)
Domain Model Domain Model
A RD.070 Determine Audit and Control
Requirements
Audit and Control Requirements Audit and Control Requirements
A RD.130.1 Develop Baseline Architecture
Description
Architecture Description Architecture Description
A RD.134 Identify New Software Release Changes Software Release Changes Summary Refer to the Task Overview for guidance.
A RD.136 Perform Custom Extension Impact
Analysis
Custom Extension Impact Analysis Refer to the Task Overview for guidance.
A RD.138 Perform Data Impact Analysis Data Impact Analysis Refer to the Task Overview for guidance.
A RD.140.1 Create Requirements Specification Requirements Specification Requirements Specification
A RD.150.1 Review Requirements Specification Reviewed Requirements Specification Review Results
Elaboration Phase
B RD.011.2 Develop Future Process Model Future Process Model Refer to the Task Overview for guidance.
B RD.042.2 Develop Glossary Glossary Refer to the Task Overview for guidance.
B RD.045.2 Prioritize Requirements (MoSCoW) MoSCoW List Refer to the Task Overview for guidance.
B RD.140.2 Create Requirements Specification Requirements Specification Requirements Specification
B RD.150.2 Review Requirements Specification Reviewed Requirements Specification Review Results
Construction Phase
C RD.042.3 Develop Glossary Glossary Refer to the Task Overview for guidance.
C RD.045.3 Prioritize Requirements (MoSCoW) MoSCoW List Refer to the Task Overview for guidance.
C RD.130.2 Develop Baseline Architecture
Description
Architecture Description Refer to the Task Overview for guidance.
Production Phase
E RD.160 Convert Project Views to Reusable
Viewpoints
New Reusable Viewpoints Refer to the Task Overview for guidance.
Back to Top
[RA] Requirements Analysis
Phase Task Overview Work Product Template
Inception Phase
A RA.010 Simulate Business Process Business Process Simulation Refer to the Task Overview for guidance.
A RA.015 Develop Business Use Case Model Business Use Case Model Business Use Case Model
Business Use Case Model-Visio Template and
Stencil
A RA.019 Define Project Reference Architecture Project Reference Architecture Refer to the Task Overview for guidance.
A RA.021.1 Capture User Stories User Story User Story
A RA.023.1 Develop Use Case Model Use Case Model Use Case Model-Word
Use Case Model-PowerPoint
Use Case Model-Visio Template and Stencil
A RA.025.1 Identify Candidate Services Service Portfolio - Candidate Services Service Portfolio
A RA.027.1 Identify Candidate Business Rules Candidate Business Rules Candidate Business Rules
A RA.028.1 Populate Business Rules Repository Populated Business Rules Repository Refer to the Task Overview for guidance.
A RA.030.1 Validate Conceptual Prototype Validated Conceptual Prototype Refer to the Task Overview for guidance.
Elaboration Phase
B RA.021.2 Capture User Stories User Story User Story
B RA.023.2 Develop Use Case Model Use Case Model Refer to the Task Overview for guidance.
B RA.024.1 Develop Use Case Details Use Case Specification Use Case Specification-Word
Use Case Specification-PowerPoint
B RA.025.2 Identify Candidate Services Service Portfolio - Candidate Services Refer to the Task Overview for guidance.
B RA.026.1 Populate Services Repository Populated Services Repository Refer to the Task Overview for guidance.
B RA.027.2 Identify Candidate Business Rules Candidate Business Rules Refer to the Task Overview for guidance.
B RA.028.2 Populate Business Rules Repository Populated Business Rules Repository Refer to the Task Overview for guidance.
B RA.030.2 Validate Conceptual Prototype Validated Conceptual Prototype Refer to the Task Overview for guidance.
B RA.035 Develop High-Level Software
Architecture Description
Architecture Description Refer to the Task Overview for guidance.
B RA.055.1 Document Business Procedures Business Procedure Documentation Business Procedure Documentation
B RA.085 Validate Functional Prototype Validated Functional Prototype Validated Functional Prototype
B RA.095 Validate User Interface Standards
Prototype
Validated User Interface Standards Prototype Refer to the Task Overview for guidance.
B RA.160 Conduct Business Data Source Gap
Analysis
Business Data Source Gap Analysis Data Source Gap Matrix
B RA.170.1 Conduct Data Quality Assessment High-Level Data Quality Assessment HIgh-Level Data Quality Assessment
B RA.180.1 Review Use Case Model Reviewed Use Case Model Review Results
Construction Phase
C RA.021.2 Capture User Stories User Story User Story
C RA.023.3 Develop Use Case Model Use Case Model Refer to the Task Overview for guidance.
C RA.024.2 Develop Use Case Details Use Case Specification Use Case Specification-Word
Use Case Specification-PowerPoint
C RA.025.3 Identify Candidate Services Service Portfolio - Candidate Services Refer to the Task Overview for guidance.
C RA.026.2 Populate Services Repository Populated Services Repository Refer to the Task Overview for guidance.
C RA.027.3 Identify Candidate Business Rules Candidate Business Rules Refer to the Task Overview for guidance.
C RA.028.3 Populate Business Rules Repository Populated Business Rules Repository Refer to the Task Overview for guidance.
C RA.055.2 Document Business Procedures Business Procedure Documentation Refer to the Task Overview for guidance.
C RA.170.2 Conduct Data Quality Assessment High-Level Data Quality Assessment Refer to the Task Overview for guidance.
C RA.180.2 Review Use Case Model Reviewed Use Case Model Review Results
Back to Top
[MC] Mapping and Configuration
Phase Task Overview Work Product Template
Inception Phase
A MC.010.1 Define Business Data Structures Business Data Structures Business Data Structures
A MC.020 Define Business Data Structure Setups Business Data Structure Setups Business Data Structure Setups
A MC.090.1 Conduct Reporting Fit Analysis Reporting Fit Analysis Reporting Fit Analysis
Elaboration Phase
B MC.010.2 Define Business Data Structures Business Data Structures Refer to the Task Overview for guidance.
B MC.030 Map Business Requirements Mapped Business Requirements Business Requirements Mapping Form
B MC.040 Gather Setup Information Setup Information Setup Information
B MC.050.1 Define Application Setups Application Setup Documents Application Setup-Excel
Application Setup Document-Word
B MC.060 Document Functional Security Functional Security Setup Information Functional Security Setup Information
B MC.070 Prepare Configuration Prototype
Environment
Configuration Prototype Environment Refer to the Task Overview for guidance.
B MC.080 Conduct Configuration Prototyping
Workshop
Validated Configuration Configuration Prototyping Workshop Strategy and
Plan
B MC.090.2 Conduct Reporting Fit Analysis Reporting Fit Analysis Reporting Fit Analysis
B MC.100 Define and Estimate Application
Extensions
Application Extension Definition and Estimates Refer to the Task Overview for guidance.
B MC.110 Define Gap Resolutions Gap Resolutions Refer to the Task Overview for guidance.
Construction Phase
C MC.050.2 Define Application Setups Application Setup Documents Refer to the Task Overview for guidance.
Back to Top
[AN] Analysis
Phase Task Overview Work Product Template
Elaboration Phase
B AN.035.1 Update Existing Analysis Specification Updated Analysis Specification Refer to the Task Overview for guidance.
B AN.040.1 Develop Analysis Architecture
Description
Architecture Description Refer to the Task Overview for guidance.
B AN.050.1 Analyze Data Data Analysis Analysis Model
B AN.060.1 Analyze Behavior Behavior Analysis Refer to the Task Overview for guidance.
B AN.070.1 Analyze Business Rules Business Rules Analysis Refer to the Task Overview for guidance.
B AN.080.1 Analyze Services Service Portfolio - Proposed Services Service Portfolio
B AN.085.1 Define Service Service Definition Service Contract
Project Contracts Portfolio
B AN.090.1 Analyze User Interface User Interface Analysis Refer to the Task Overview for guidance.
B AN.100.1 Prepare Analysis Specification Analysis Specification Analysis Specification
B AN.110.1 Review Analysis Model Reviewed Analysis Model Review Results
Construction Phase
C AN.035.2 Update Existing Analysis Specification Updated Analysis Specification Refer to the Task Overview for guidance.
C AN.040.2 Develop Analysis Architecture
Description
Architecture Description Refer to the Task Overview for guidance.
C AN.050.2 Analyze Data Data Analysis Analysis Model
C AN.060.2 Analyze Behavior Behavior Analysis Refer to the Task Overview for guidance.
C AN.070.2 Analyze Business Rules Business Rules Analysis Refer to the Task Overview for guidance.
C AN.080.2 Analyze Services Service Portfolio - Proposed Services Refer to the Task Overview for guidance.
C AN.085.2 Define Service Service Definition Service Contract
Project Contracts Portfolio
C AN.090.2 Analyze User Interface User Interface Analysis Refer to the Task Overview for guidance.
C AN.100.2 Prepare Analysis Specification Analysis Specification Analysis Specification
C AN.110.2 Review Analysis Model Reviewed Analysis Model Review Results
Back to Top
[DS] Design
Phase Task Overview Work Product Template
Elaboration Phase
B DS.020 Define Application Extension Strategy Application Extension Strategy Application Extension Strategy
B DS.035.1 Update Existing Design Specification Updated Design Specification Refer to the Task Overview for guidance.
B DS.040.1 Develop Design Architecture Description Architecture Description Refer to the Task Overview for guidance.
B DS.050 Determine Design and Build Standards Design and Build Standards Refer to the Task Overview for guidance.
B DS.060 Define Business Rules Implementation
Strategy
Business Rules Implementation Strategy Refer to the Task Overview for guidance.
B DS.070 Define SOA Implementation Strategy SOA Implementation Strategy Refer to the Task Overview for guidance.
B DS.080.1 Design Software Components Software Component Design Refer to the Task Overview for guidance.
B DS.090.1 Design Data Component Data Design Refer to the Task Overview for guidance.
B DS.100.1 Design Behavior Component Behavior Design Refer to the Task Overview for guidance.
B DS.110.1 Design Business Rules Business Rules Design Refer to the Task Overview for guidance.
B DS.120.1 Design Services Service Design Refer to the Task Overview for guidance.
B DS.130.1 Design User Interface User Interface Design Refer to the Task Overview for guidance.
B DS.140.1 Prepare Design Specification Design Specification Design Specification
B DS.150.1 Develop Database Design Logical Database Design Logical Database Design
B DS.160.1 Review Design Model Reviewed Design Model Review Results
Construction Phase
C DS.035.2 Update Existing Design Specification Updated Design Specification Refer to the Task Overview for guidance.
C DS.040.2 Develop Design Architecture Description Architecture Description Refer to the Task Overview for guidance.
C DS.080.2 Design Software Components Software Component Design Refer to the Task Overview for guidance.
C DS.090.2 Design Data Component Data Design Refer to the Task Overview for guidance.
C DS.100.2 Design Behavior Component Behavior Design Refer to the Task Overview for guidance.
C DS.110.2 Design Business Rules Business Rules Design Refer to the Task Overview for guidance.
C DS.120.2 Design Services Service Design Refer to the Task Overview for guidance.
C DS.130.2 Design User Interface User Interface Design Refer to the Task Overview for guidance.
C DS.140.2 Prepare Design Specification Design Specification Design Specification
C DS.150.2 Develop Database Design Logical Database Design Refer to the Task Overview for guidance.
C DS.160.2 Review Design Model Reviewed Design Model Review Results
Back to Top
[IM] Implementation
Phase Task Overview Work Product Template
Inception Phase
A IM.005.1 Develop Conceptual Prototype Conceptual Prototype Refer to the Task Overview for guidance.
Elaboration Phase
B IM.005.2 Develop Conceptual Prototype Conceptual Prototype Refer to the Task Overview for guidance.
B IM.007.1 Prepare Development Environment Development Environment Development Environment
B IM.010 Develop Functional Prototype Functional Prototype Refer to the Task Overview for guidance.
B IM.020 Develop Architectural Foundation Architectural Foundation Refer to the Task Overview for guidance.
B IM.040.1 Implement Database Implemented Database Physical Database Design
B IM.053.1 Register Services Populated Services Registry Refer to the Task Overview for guidance.
B IM.055.1 Perform Business Rules Implementation
(Rules Engine)
Implemented Business Rules (Rules Engine) Refer to the Task Overview for guidance.
B IM.060.1 Perform Component Review Component Review Results Review Results
B IM.085 Develop User Interface Standards
Prototype
User Interface Standards Prototype Refer to the Task Overview for guidance.
Construction Phase
C IM.007.2 Prepare Development Environment Development Environment Refer to the Task Overview for guidance.
C IM.040.2 Implement Database Implemented Database Refer to the Task Overview for guidance.
C IM.050 Implement Components Implemented Components Refer to the Task Overview for guidance.
C IM.053.2 Register Services Populated Services Registry Refer to the Task Overview for guidance.
C IM.055.2 Perform Business Rules Implementation
(Rules Engine)
Implemented Business Rules (Rules Engine) Refer to the Task Overview for guidance.
C IM.060.2 Perform Component Review Component Review Results Review Results
C IM.070 Assemble Components Assembled Components Refer to the Task Overview for guidance.
C IM.080 Integrate Services Integrated Services Refer to the Task Overview for guidance.
C IM.090 Create Installation Routines Installation Routines Installation Instructions
Back to Top
[TE] Testing
Phase Task Overview Work Product Template
Inception Phase
A TE.005.1 Determine Testing Requirements Testing Requirements Testing Requirements
Elaboration Phase
B TE.005.2 Determine Testing Requirements Testing Requirements Refer to the Task Overview for guidance.
B TE.010 Develop Testing Strategy Testing Strategy Testing Strategy
B TE.015.1 Develop Integration Test Plan Integration Test Plan Integration Test Plan
B TE.018.1 Prepare Static Test Data Static Test Data Static Test Data
B TE.020.1 Develop Unit Test Scripts Unit Test Scripts Unit Test Checklists
Unit Test Scenarios
B TE.025.1 Create System Test Scenarios System Test Scenarios System Test Scenarios
B TE.025.2 Create System Test Scenarios System Test Scenarios System Test Scenarios
B TE.030.1 Perform Unit Test Unit-Tested Components Refer to the Task Overview for guidance.
B TE.035.1 Create Integration Test Scenarios Integration Test Scenarios Integration Test Scenarios
B TE.038.1 Prepare Integration Test Environment Integration Test Environment Integration Test Environment
B TE.040.1 Perform Integration Test Integration-Tested Components Integration Test Results
B TE.050.1 Develop System Test Plan System Test Plan System Test Plan
B TE.060.1 Prepare System Test Environment System Test Environment System Test Environment
B TE.070.1 Perform System Test System-Tested Applications System Test Results
B TE.072.1 Test Pre-Upgrade Steps Pre-Upgrade Checklist Refer to the Task Overview for guidance.
B TE.073.1 Test Packaged Software Upgrade Packaged Software Upgrade Checklist Refer to the Task Overview for guidance.
B TE.074.1 Test Post-Upgrade Steps Post-Upgrade Checklist Refer to the Task Overview for guidance.
B TE.075.1 Perform Post-Upgrade Reconciliation
Testing
Reconciliation Test Report Refer to the Task Overview for guidance.
B TE.076.1 Review Upgrade Test Results Upgrade Test Analysis Upgrade Test Analysis
B TE.080 Develop Systems Integration Test Plan Systems Integration Test Plan Systems Integration Test Plan
B TE.082 Develop Acceptance Test Plan Acceptance Test Plan Refer to the Task Overview for guidance.
Construction Phase
C TE.015.2 Develop Integration Test Plan Integration Test Plan Refer to the Task Overview for guidance.
C TE.018.2 Prepare Static Test Data Static Test Data Refer to the Task Overview for guidance.
C TE.019.1 Collect, Assess and Refine KPI
Measurements
Key Business Strategies and Objectives Refer to the Task Overview for guidance.
C TE.020.2 Develop Unit Test Scripts Unit Test Scripts Unit Test Checklists
Unit Test Scenarios
C TE.025.3 Create System Test Scenarios System Test Scenarios System Test Scenarios
C TE.030.2 Perform Unit Test Unit-Tested Components Refer to the Task Overview for guidance.
C TE.035.2 Create Integration Test Scenarios Integration Test Scenarios Integration Test Scenarios
C TE.038.2 Prepare Integration Test Environment Integration Test Environment Refer to the Task Overview for guidance.
C TE.040.2 Perform Integration Test Integration-Tested Components Integration Test Results
C TE.050.2 Develop System Test Plan System Test Plan Refer to the Task Overview for guidance.
C TE.060.2 Prepare System Test Environment System Test Environment System Test Environment
C TE.065 Perform Installation Test Tested Installation Routines Refer to the Task Overview for guidance.
C TE.070.2 Perform System Test System-Tested Applications System Test Results
C TE.072.2 Test Pre-Upgrade Steps Pre-Upgrade Checklist Refer to the Task Overview for guidance.
C TE.073.2 Test Packaged Software Upgrade Packaged Software Upgrade Checklist Refer to the Task Overview for guidance.
C TE.074.2 Test Post-Upgrade Steps Post-Upgrade Checklist Refer to the Task Overview for guidance.
C TE.075.2 Perform Post-Upgrade Reconciliation
Testing
Reconciliation Test Report Refer to the Task Overview for guidance.
C TE.076.2 Review Upgrade Test Results Upgrade Test Analysis Refer to the Task Overview for guidance.
C TE.085 Prepare Systems Integration Test
Environment
Systems Integration Test Environment Systems Integration Test Environment
C TE.090 Develop Systems Integration Test
Scenarios
Systems Integration Test Scenarios Systems Integration Test Scenarios
C TE.100 Perform Systems Integration Test Integration-Tested System Systems Integration Test Results
Transition Phase
D TE.105 Prepare Users for Testing Prepared Users for Testing Refer to the Task Overview for guidance.
D TE.110 Prepare Acceptance Test Environment Acceptance Test Environment Acceptance Test Environment
D TE.120 Support Acceptance Test Acceptance Test Results Acceptance Test Results
Production Phase
E TE.019.2 Collect, Assess and Refine KPI
Measurements
Key Business Strategies and Objectives Refer to the Task Overview for guidance.
Back to Top
[PT] Performance Management
Phase Task Overview Work Product Template
Inception Phase
A PT.010 Conduct Performance Management
Workshop
Performance Management Workshop Results Refer to the Task Overview for guidance.
Elaboration Phase
B PT.020 Define Performance Management
Requirements and Strategy
Performance Management Requirements and
Strategy
Performance Management Requirements and
Strategy
B PT.030 Define Performance Testing Strategy Performance Testing Strategy Performance Testing Strategy
B PT.040 Identify Performance Testing Models and
Scenarios
Performance Testing Models and Scenarios Performance Testing Models and Scenarios
B PT.050 Design Performance Test Scripts and
Programs
Performance Test Scripts and Programs Design Performance Test Scripts and Programs Design
B PT.060 Design Performance Test Data and Load
Programs
Performance Test Data and Load Programs
Design
Designed Performance Test Data
Designed Test Load Programs
Construction Phase
C PT.070 Build Performance Test Scripts and
Programs
Performance Test Scripts and Programs Refer to the Task Overview for guidance.
C PT.080 Construct Performance Test Environment
and Database
Performance Test Environment and Database Performance Test Environment
C PT.090 Conduct Performance Test Dress
Rehearsal
Validated Performance Test and Environment Refer to the Task Overview for guidance.
Transition Phase
D PT.100 Execute Performance Test Performance Test Results Performance Test Results
D PT.110 Create Performance Test Report Performance Test Report Performance Test Report
Production Phase
E PT.120 Conduct Production Performance
Management
Managed Production Environment Refer to the Task Overview for guidance.
Back to Top
[TA] Technical Architecture
Phase Task Overview Work Product Template
Inception Phase
A TA.004 Perform Technical Architecture Impact
Analysis
Technical Architecture Impact Analysis Refer to the Task Overview for guidance.
A TA.010 Conduct Technical Architecture Workshop Technical Architecture Workshop Results Refer to the Task Overview for guidance.
Elaboration Phase
B TA.006 Define Technical Prototype Subprojects Technical Prototype Approach Refer to the Task Overview for guidance.
B TA.020 Define Technical Architecture Technical Architecture Requirements and Strategy Technical Architecture Requirements and Strategy
Requirements and Strategy
B TA.030 Define Integration Requirements and
Strategy
Integration Architecture Strategy Integration Architecture Strategy
B TA.040 Define Reporting and Information Access
Strategy
Reporting and Information Access Strategy Reporting and Information Access Strategy
B TA.050 Define Disaster Recovery Strategy Disaster Recovery Strategy Disaster Recovery Strategy
B TA.060 Define System Operations and
Management Strategy
System Operations and Management Strategy System Operations and Management Strategy
B TA.070 Define Initial Architecture and Application
Mapping
Initial Architecture and Application Mapping Initial Architecture and Application Mapping
B TA.080 Define Backup and Recovery Strategy Backup and Recovery Strategy Backup and Recovery Strategy
B TA.090 Develop Security and Control Strategy Security and Control Strategy Security and Control Strategy
Construction Phase
C TA.100 Define System Management Procedures System Management Guide System Management Guide
C TA.110 Define Operational Testing Plan Operational Testing Plan Operational Testing Plan
C TA.120 Conduct Operational Testing Operational Test Results Operational Test Results
C TA.130 Conduct Backup and Recovery Test Backup and Recovery Test Results Backup and Recovery Test Results
C TA.140 Conduct Disaster Recovery Test Disaster Recovery Test Results Disaster Recovery Test Results
C TA.150 Define Final Platform and Network
Architecture
Final Platform and Network Architecture Final Platform and Network Architecture
C TA.160 Define System Capacity Plan System Capacity Plan System Capacity Plan
Back to Top
[CV] Data Acquisition and Conversion
Phase Task Overview Work Product Template
Inception Phase
A CV.010 Define Data Acquisition and Conversion
Requirements
Data Acquisition and Conversion Requirements Data Acquisition and Conversion Requirements
Elaboration Phase
B CV.020 Define Data Acquisition, Conversion and
Data Quality Strategy
Data Acquisition, Conversion and Data Quality
Strategy
Data Acquisition, Conversion and Data Quality
Strategy
B CV.025 Define Data Acquisition and Conversion
Standards
Data Acquisition and Conversion Standards Data Acquisition and Conversion Standards
B CV.027.1 Perform Data Mapping Data Mapping Data Mapping
B CV.030.1 Prepare Conversion Environment (Initial
Load)
Conversion Environment (Initial Load) Conversion Environment (Initial Load)
B CV.035.1 Define Manual Conversion Procedures
(Initial Load)
Manual Conversion Procedures (Initial Load) Manual Conversion Procedures (Initial Load)
B CV.040.1 Design Conversion Components (Initial
Load)
Conversion Component Designs (Initial Load) Conversion Component Designs (Initial Load)
B CV.050.1 Prepare Conversion Test Plans (Initial
Load)
Conversion Test Plans (Initial Load) Conversion Test Plans (Initial Load)
B CV.055.1 Implement Conversion Components
(Initial Load)
Conversion Components (Initial Load) Conversion Components (Initial Load)
B CV.060.1 Perform Conversion Component Unit
Test (Initial Load)
Unit-Tested Conversion Components (Initial Load) Refer to the Task Overview for guidance.
B CV.062.1 Perform Conversion Component
Business Object Test (Initial Load)
Business Object-Tested Conversion Components
(Initial Load)
Refer to the Task Overview for guidance.
B CV.063.1 Perform Conversion Component
Validation Test (Initial Load)
Validation-Tested Conversion Components (Initial
Load)
Refer to the Task Overview for guidance.
Construction Phase
C CV.027.2 Perform Data Mapping Data Mapping Refer to the Task Overview for guidance.
C CV.030.2 Prepare Conversion Environment (Initial
Load)
Conversion Environment (Initial Load) Refer to the Task Overview for guidance.
C CV.035.2 Define Manual Conversion Procedures
(Initial Load)
Manual Conversion Procedures (Initial Load) Refer to the Task Overview for guidance.
C CV.040.2 Design Conversion Components (Initial
Load)
Conversion Component Designs (Initial Load) Conversion Component Designs (Initial Load)
C CV.050.2 Prepare Conversion Test Plans (Initial
Load)
Conversion Test Plans (Initial Load) Conversion Test Plans (Initial Load)
C CV.055.2 Implement Conversion Components Conversion Components (Initial Load) Conversion Components (Initial Load)
(Initial Load)
C CV.060.2 Perform Conversion Component Unit
Test (Initial Load)
Unit-Tested Conversion Components (Initial Load) Refer to the Task Overview for guidance.
C CV.062.2 Perform Conversion Component
Business Object Test (Initial Load)
Business Object-Tested Conversion Components
(Initial Load)
Refer to the Task Overview for guidance.
C CV.063.2 Perform Conversion Component
Validation Test (Initial Load)
Validation-Tested Conversion Components (Initial
Load)
Refer to the Task Overview for guidance.
C CV.064.1 Install Conversion Components (Initial
Load)
Installed Conversion Components (Initial Load) Installed Conversion Components (Initial Load)
C CV.065.1 Convert and Verify Data (Initial Load) Converted and Verified Data (Initial Load) Converted and Verified Data (Initial Load)
C CV.068.1 Clean Data Clean Legacy Data Refer to the Task Overview for guidance.
Transition Phase
D CV.064.2 Install Conversion Components (Initial
Load)
Installed Conversion Components (Initial Load) Installed Conversion Components (Initial Load)
D CV.065.2 Convert and Verify Data (Initial Load) Converted and Verified Data (Initial Load) Converted and Verified Data (Initial Load)
D CV.068.2 Clean Data Clean Legacy Data Refer to the Task Overview for guidance.
Back to Top
[DO] Documentation
Phase Task Overview Work Product Template
Inception Phase
A DO.010 Define Documentation Requirements and
Strategy
Documentation Requirements and Strategy Documentation Requirements and Strategy
Elaboration Phase
B DO.020 Define Documentation Standards and
Procedures
Documentation Standards and Procedures Documentation Standards and Procedures
B DO.040 Prepare Documentation Environment Documentation Environment Documentation Environment
Construction Phase
C DO.060 Publish User Reference Manual User Reference Manual User Reference Manual
C DO.070 Publish User Guide User Guide User Guide
C DO.080 Publish Technical Reference Material Technical Reference Material Technical Reference Material
C DO.100 Produce Online Help Online Help Refer to the Task Overview for guidance.
Transition Phase
D DO.110 Finalize Documentation Final Documentation Work Products Refer to the Task Overview for guidance.
Back to Top
[OCM] Organizational Change Management
Phase Task Overview Work Product Template
Inception Phase
A OCM.010 Create and Manage Ad Hoc
Communications
Ad Hoc Communications Ad Hoc Communications Strategy and Approach
A OCM.020 Prepare for Executive Alignment
Workshop
Executive Alignment Workshop Materials Executive Alignment Workshop Materials
Executive Alignment Workshop Presentation
A OCM.030 Conduct Executive Alignment
Workshop
Executive Business Objectives and Governance
Rules
Executive Business Objectives and Governance
Rules
A OCM.040 Build and Deploy Sponsorship Program Sponsorship Program Sponsorship Program
A OCM.050 Prepare for Team-Building Workshop Team-Building Workshop Materials Team-Building Workshop Materials
A OCM.060 Conduct Team-Building Workshop Cohesive Project Team Refer to the Task Overview for guidance.
A OCM.070 Design Managers' Project Alignment
Workshop
Managers' Project Alignment Workshop Materials Refer to the Task Overview for guidance.
A OCM.080 Conduct Managers' Project Alignment
Workshop
Aligned Managers Refer to the Task Overview for guidance.
A OCM.090 Design Change Agent Workshop Change Agent Workshop Materials Change Agent Workshop Materials
A OCM.100 Conduct Change Agent Workshop Enabled Change Agents Refer to the Task Overview for guidance.
A OCM.110 Develop Change Readiness
Assessment Strategy and Tools
Change Readiness Assessment Strategy and
Tools
Change Readiness Assessment Strategy and
Tools
A OCM.120 Conduct Change Readiness
Assessment and Analyze Data
Change Readiness Assessment Analysis and
Recommendations
Change Readiness Assessment Analysis and
Recommendations
A OCM.130 Build Communication Strategy and
Change Management Roadmap
Communication Strategy and Change
Management Roadmap
Communication Strategy
Change Management Roadmap
A OCM.140 Develop Communication Campaign Communication Campaign Communication Campaign
A OCM.150.1 Conduct Change Management
Roadmap / Communication Campaign
Change Management Roadmap / Communication
Events
Refer to the Task Overview for guidance.
Elaboration Phase
B OCM.150.2 Conduct Change Management
Roadmap / Communication Campaign
Change Management Roadmap / Communication
Events
Refer to the Task Overview for guidance.
B OCM.155.1 Monitor Change Management
Roadmap / Communication Campaign
Effectiveness
Change Management Roadmap / Communication
Campaign Effectiveness Assessment
Change Management Roadmap / Communication
Campaign Effectiveness Assessment
B OCM.160 Prepare Business Process Impact
Inventory
Business Process Impact Inventory Business Process Impact Inventory
Construction Phase
C OCM.150.3 Conduct Change Management
Roadmap / Communication Campaign
Change Management Roadmap / Communication
Events
Refer to the Task Overview for guidance.
C OCM.155.2 Monitor Change Management
Roadmap / Communication Campaign
Effectiveness
Change Management Roadmap / Communication
Campaign Effectiveness Assessment
Change Management Roadmap / Communication
Campaign Effectiveness Assessment
C OCM.170 Collect and Analyze J ob Change Data J ob Impact Analysis J ob Impact Analysis
C OCM.180 Determine Impact of J ob Changes J ob Impact Diagnosis J ob Impact Diagnosis
C OCM.190 Prepare HR Transition Plan HR Transition Plan HR Transition Plan
C OCM.200 Design Managers' Unit / Department
Impact Workshop
Managers' Unit / Department Impact Workshop
Materials
Managers' Unit / Department Impact Workshop
Materials
C OCM.210 Conduct Managers' Unit / Department
Impact Workshop
Enabled Managers Refer to the Task Overview for guidance.
Transition Phase
D OCM.150.4 Conduct Change Management
Roadmap / Communication Campaign
Change Management Roadmap / Communication
Events
Refer to the Task Overview for guidance.
D OCM.155.3 Monitor Change Management
Roadmap / Communication Campaign
Effectiveness
Change Management Roadmap / Communication
Campaign Effectiveness Assessment
Change Management Roadmap / Communication
Campaign Effectiveness Assessment
D OCM.220 Prepare Assessment of Impact on IT
Groups
IT Alignment Diagnosis Grid IT Alignment Diagnosis Grid
D OCM.230 Prepare IT Transition Plan IT Transition Plan IT Transition Plan
Production Phase
E OCM.150.5 Conduct Change Management
Roadmap / Communication Campaign
Change Management Roadmap / Communication
Events
Refer to the Task Overview for guidance.
E OCM.155.4 Monitor Change Management
Roadmap / Communication Campaign
Effectiveness
Change Management Roadmap / Communication
Campaign Effectiveness Assessment
Change Management Roadmap / Communication
Campaign Effectiveness Assessment
E OCM.250 Measure Organizational Change
Effectiveness
Organizational Effectiveness Assessment Organizational Effectiveness Assessment
E OCM.260 Implement IT Transition Plan Aligned IT Organization Refer to the Task Overview for guidance.
Back to Top
[TR] Training
Phase Task Overview Work Product Template
Inception Phase
A TR.010.1 Define Training Strategy Education and Training Strategy Refer to the Task Overview for guidance.
A TR.020 Prepare Project Team Learning Plan Project Team Learning Plan Project Team Learning Plan
A TR.030 Prepare Project Team Learning
Environment
Project Team Learning Environment Working Learning Environment
A TR.040 Develop Project Team Learningware Project Team Learningware Refer to the Task Overview for guidance.
A TR.050 Conduct Project Team Learning Events Skilled Project Team Project Team Learning Events Administration
Training Preparation Checklist
Elaboration Phase
B TR.010.2 Define Training Strategy Education and Training Strategy Refer to the Task Overview for guidance.
Construction Phase
C TR.060 Conduct User Learning Needs Analysis User Learning Needs Analysis User Learning Needs Analysis
C TR.070 Develop User Learning Plan User Learning Plan User Learning Plan
C TR.080 Develop User Learningware User Learningware User Learningware
C TR.090 Prepare User Learning Environment Configured User Learning Environment Configured User Learning Environment
C TR.100.1 Conduct User Learning Events Skilled Users User Learning Events Administration
Training Preparation Checklist
Transition Phase
D TR.100.2 Conduct User Learning Events Skilled Users User Learning Events Administration
Training Preparation Checklist
Back to Top
[TS] Transition
Phase Task Overview Work Product Template
Elaboration Phase
B TS.020.1 Define Cutover Strategy Cutover Strategy Cutover Strategy
Construction Phase
C TS.020.2 Define Cutover Strategy Cutover Strategy Refer to the Task Overview for guidance.
C TS.030 Develop Installation Plan Installation Plan Installation Plan
C TS.040 Design Production Support Infrastructure Production Support Infrastructure Design Production Support Infrastructure Design
Transition Phase
D TS.050 Prepare Production Environment Production Environment Refer to the Task Overview for guidance.
D TS.052 Implement Production Support
Infrastructure
Production Support Infrastructure Refer to the Task Overview for guidance.
D TS.054 Perform Pre-Upgrade Steps Pre-Upgrade Checklist Refer to the Task Overview for guidance.
D TS.055 Upgrade Production Environment Upgraded Production Environment Refer to the Task Overview for guidance.
D TS.056 Perform Post-Upgrade Steps Post-Upgrade Checklist Refer to the Task Overview for guidance.
D TS.057 Revise Application Setups Configured Applications Refer to the Task Overview for guidance.
D TS.058 Verify Production Readiness Production-Ready System Refer to the Task Overview for guidance.
D TS.060 Go Production System In Production Refer to the Task Overview for guidance.
D TS.070 Shut Down Legacy System Legacy System Shut Down Refer to the Task Overview for guidance.
Back to Top
[PS] Operations and Support
Phase Task Overview Work Product Template
Production Phase
E PS.010 Audit System System Evaluation Refer to the Task Overview for guidance.
E PS.050 Analyze Problems Fault Corrections Refer to the Task Overview for guidance.
E PS.060 Monitor and Respond to System Problems Problem Log Refer to the Task Overview for guidance.
E PS.135 Determine Future Functional
Enhancements
Future Functional Enhancements Refer to the Task Overview for guidance.
E PS.140 Plan Enhancements Future MoSCoW List Refer to the Task Overview for guidance.
Back to Top
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Method Overview
Method Navigation Current Page Navigation
ORACLE

UNIFIED METHOD (OUM) OVERVIEW


INTRODUCTION
Oracle is evolving the Oracle

Unified Method (OUM) to realize the vision of supporting the entire Enterprise IT lifecycle, including support for the successful
implementation of every Oracle product. You can tailor OUM to support your specific project situation. With its ready-made templates, guidelines, and scalable work
breakdown structure, OUM provides the programmatic tools you need to manage the risks associated with your project.
OUM provides support for Application Implementation, Cloud Application Services Implementation, and Software Upgrade projects as well as the complete range of
technology projects including Business Intelligence (BI), Enterprise Security, WebCenter, Service-Oriented Architecture (SOA), Application Integration Architecture (AIA),
Business Process Management (BPM), Enterprise Integration, and Custom Software. Detailed techniques and tool guidance is provided, including a supplemental guide
related to Oracle UPK and Tutor. Refer to the What's New? page for details on the features of this release.
OUM includes three Focus Areas Manage, Envision, and Implement. OUM's Manage focus area provides a framework in which all types of projects can be planned,
estimated, controlled, and completed in a consistent manner. OUMs Envision focus area deals with development and maintenance of enterprise level IT strategy,
architecture, and governance. Envision also assists in the transition from enterprise-level planning and strategy activities to the identification and initiation of specific
projects. The Implement focus area provides a framework to develop and implement Oracle-based business solutions with precise development and rapid deployment.
In order to understand the connection between the artifacts produced in the Envision focus area and how they relate directly to the tasks in the Implement focus area you
should review the Envision Touch Points.
The diagram below shows how the Envision, Manage, and Implement focus areas fit together to form OUM:
OUM couples the experience of Oracle's global practitioners with an extended Unified Process-based framework. It provides this collection of leading practices organized
as a series of processes or workflows that can be assembled and scaled to achieve various information technology related business objectives. OUM also leverages
Oracles intellectual capital by reusing processes, tasks, and templates from Oracle's complete portfolio of existing methods. For further reading on UP, see The Unified
Software Development Process.
OUM also possesses the following properties:
Focuses on the business to assure stakeholder acceptance and delivery of the development effort's values, goals, and objectives.
Centers on architecture to provide a clear perspective of the whole system. During Inception and Elaboration, the objective is to define an executable architecture
before committing resources to a full-scale development and implementation effort.
Encourages adaptability and balance for scalable delivery across small and large projects possessing disparate resources and skill levels in order to realize
repeatable results.
Provides rapid implementation techniques that enable building business solutions in short time frames.
Uses non-proprietary and referential standards, such as the Unified Modeling Language (UML) and de facto standards like the Unified Software Development
Process
You should use OUM as a guideline for performing information technology projects, but keep in mind that every project is different and that you need to adjust project
activities according to each situation. Do not hesitate to add, remove, or rearrange tasks, but be sure to reflect those changes in your estimates and risk management
planning.
OUM is evolving. The vision is to support the entire Enterprise IT lifecycle, including support for the successful implementation of every Oracle product. Upcoming
releases of OUM will provide enhanced support for Oracle's full complement of enterprise application suites including product-suite specific materials and guidance for
tailoring OUM to support various project types.
Your contributions and feedback are welcome and appreciated. Improvements to OUM continue to be made based upon the experience that Oracle acquires through
its myriad interactions with users of Oracle's software products. Please contribute your thoughts, comments, ideas, and artifacts to Oracle's Global Methods team so that
we may continue to improve this body of work. Contact Oracle's Global Methods team at ominfo_us@oracle.com.
OUM Approach
OUM is built on five main principles derived from the Unified Process, the Dynamic Systems Development Method (DSDM), and Oracle's legacy methods. Those are:
Iterative and Incremental
Business Process and Use Case-Driven
Architecture-Centric
Flexible and Scalable
Risk-Focused
For further reading on the Dynamic Systems Development Method, see DSDM: Business Focused Development.
Iterative and Incremental
OUM, like the Unified Process (UP) from which it has been derived, employs an iterative and incremental approach to implementing software systems. In the Unified
Process, and therefore in OUM, the result of an iteration is an increment. It is important to note that the OUM definition of an increment, while consistent with UP, differs
from the definition used in DSDM. For further reading on iterations and increments, see The Unified Software Development Process.
In OUM, the terms iteration and increment are defined in a way that is consistent with these concepts. An increment is the difference between the release of one iteration
and the release of the next iteration. An iteration is a distinct set of activities conducted according to a devoted (iteration) plan and evaluation criteria that results in a
release, either internal or external.
Rather than breaking the software implementation process into steps such as requirements, analysis, design, implement, and test; the OUM Implement focus area breaks
the process into major milestones called the Lifecycle milestones. These milestones were defined by Barry Boehm and initially published in the article "Anchoring the
Software Process". The milestones occur at the phase boundaries;and serve to anchor the software implementation process. For further reading on milestones, see
"Anchoring the Software Process."
Each OUM Implement phase may also be broken down into several iterations. These iterations represent the minor milestones of the project. OUM suggests nominal
iteration counts for each phase, but the project team must develop the actual iteration plan based upon the project's characteristics. The total number of iterations in a
project may range from as few as 4 to more than 12, but is generally in the range of 4 to 10.
Remember that Parkinsons Law states that Work grows to fill available time. Therefore, OUM recommends planning iterations to be 2 to 6 weeks in length, with a bias
toward shorter lengths. The optimum length for a given iteration is based on the ability of the project team to segment or partition the work. This is normally a factor of the
solution being implemented and the structure of the project team. Project teams less experienced with an iterative approach tend to be biased toward longer iterations
because they doubt their ability to deliver value in shorter periods. This tendency should be resisted. The value of an iterative approach is to focus the project team on
specific objectives and addressing the most important risks within each iteration. As such, iterations should almost never exceed 7 or 8 weeks and typically shorter is
better.
An iteration can be thought of as a mini-project that runs through a group of tasks and activities. These activities perform a complete requirements-analysis-design-
implementation-test cycle to produce an incremental improvement to the project's active outputs that is, an increment. Each iteration also includes planning, at the front,
and preparation for release, at the end.
As illustrated in the OUM Implement overview diagram, early iterations emphasize requirements-analysis-design. These may also include implementation-test activities
(of a prototype, for example). In the Inception and Elaboration phases an iteration is most likely to result in an incremental improvement to models, documentation, and
prototypes. Later iterations have a greater emphasis on implementation and test, but will also likely include some refinement of the requirements-analysis-design outputs.
Therefore, during the Construction phase, an iteration will more likely result in an internal release of software.
OUMs iterative and incremental approach means that projects will be managed somewhat differently. OUM proposes controlled iterations, meaning that the content
and objectives of each iteration are planned early in the project and that the plan is adhered to throughout the project. The project team determines the content of the
iterations by identifying project risks and addressing the highest priority risks in the early iterations.
OUM provides extensive guidance related to managing such projects as part of the Manage focus area. Generally speaking, however, at the beginning of an OUM project,
a high-level Project Workplan is created. This workplan documents the phases, iterations, and other significant milestones of the project. The project manager uses the
high-level plan as a framework for planning successive iterations that will each result in an increment of work. Just prior to the beginning of each iteration, the project
manager develops the detailed iteration plan that will be used to manage that iteration.
Typically, each iteration is related to one or more software components and also addresses the most significant risks. The components can be defined by business
process, use case, or other groupings related to the software being implemented. During the iteration, each task and component is completed to the level agreed to at the
start of the iteration. Project teams may choose to implement component by component, to develop parts of the requirements in one iteration and complete them in
another, or to use a mixed approach. Completed components are continuously integrated into systems and subsystems through the iterations.
Rapid development techniques such as workshops and prototyping are frequently employed. User involvement is encouraged early in the process and throughout the
project. Requirements are not frozen, but rather changes are handled through the prioritized requirements (MoSCoW) list developed early in the process. As with other
Oracle method approaches, requirement changes that results in changes to the overall scope, or that fall outside of the project scope, are addressed by the normal
change control process that includes client sign-off.
Finally, it is important to note that an iterative approach does not imply that requirements are out of control or are in a state of flux. It has been shown time and again, that
properly planned and executed iterations allow for the most effective control of the changing requirements that are an inevitable, yet important part of all but the very
simplest software implementation projects.
Business Process and Use Case-Driven
Business processes and use cases are used as the primary artifacts for establishing the desired behavior of the system and for communicating this behavior among the
stakeholders.
OUM projects are able to document requirements through business process models, through use cases, and through written supplemental and quality of service
requirements. OUM guidance helps implementers to understand where each technique is appropriate and how they fit together.
Business processes modeling helps stakeholders and implementers to understand the business processes of an organization, and look at the business requirements that
are addressed by a particular business process.To complement business process models, use case models and use cases;may be used to:
Provide a consistent mechanism to link system requirements to design and test tasks
Bridge the gap between business modeling, business processes, and software system functionality
Provide a consistent thread through OUM use cases help amplify and consolidate the many other benefits of the method
Identify implicit or unstated requirements
Manage traceability of requirements through testing
Often business process models for predefined solutions exist and contain some form or description of how the user interacts with the system or how a system interacts
with another system. Where these business process models already exist, they should be reviewed as a means of gathering business requirements. The need for
additional use case modeling would depend on how well the business process models have captured the requirements of the business. Use cases become particularly
important where there is a significant gap between the functionality required by the business and the functionality provided by the predefined solution or software product
that is being employed. OUM proposes that implementers develop only the set of models and artifacts required to understand and document requirements and trace
those requirements through the implementation lifecycle.
As the project progresses and where the need to develop use cases arises, the use cases are analyzed and the system is designed and implemented to meet the
requirements captured in the use cases. The implemented components are tested to verify that they provide the business benefit described by the use cases. All of the
models (Use Case Model, Analysis Model, Design Model, Architectural Implementation, and Performance Test Transaction Models) are related to each other through
trace dependencies. Use cases are prioritized to:
Define the architecture before committing too much resource
First deliver the components with the highest value to the user
Architecture-Centric
In the context of the software lifecycle, architecture-centric means that the systems architecture is used as a primary artifact for conceptualizing, constructing, managing
and evolving the system that is being implemented.
Architecture refers to the set of significant decisions about the organization of a software system, the selection of the structural elements and their interfaces by which the
system is composed, together with their behavior as specified in the collaboration among those elements, the composition of these structural and behavioral elements
into progressively larger subsystems, and the architectural style that guides this organization.
The architecture is the collection of models that describe the system. It contains the most significant static and dynamic aspects, and an executable architecture is the
product of successive refinements. This is usually accomplished in the form of a models and prototypes, and is developed before full-scale development starts. It contains
the organization of the software system to build with structural elements and interfaces, and their behavior.
OUM is architecture-centric from the beginning of the project. An architectural baseline is defined in the initial phases and expanded in the subsequent phases to produce
high quality software systems in a cost effective way. The architectural baseline provides an infrastructure, often a framework that supports continuously adding or
replacing components through the iterations to minimize the effect on the rest of the application. For further reading on architecture-centric, see The Unified Software
Development Process.
Flexible and Scalable
Traditionally, projects have been focused on addressing the contents of a requirements document or rigorously conforming to an existing set of artifacts. Often, especially
where iterative and incremental techniques have not been employed, these requirements may be inaccurate, the previous deliverables may be flawed, or the business
needs may have changed since the start of the project. Fitness for business purpose, derived from the Dynamic Systems Development Method (DSDM) framework,
refers to the focus of delivering necessary functionality within a required timebox. The solution can be more rigorously engineered later, if such an approach is
acceptable. Our collective experience shows that applying fit-for-purpose criteria, rather than tight adherence to requirements specifications, results in an information
system that more closely aligns to the needs of the business.
In OUM, this principle is extended to refer to the execution of the method processes themselves. Project managers and practitioners are encouraged to scale OUM to be
fit-for-purpose for a given situation. It is rarely appropriate to execute every activity within OUM. OUM provides guidance for determining the core set of activities to be
executed, the level of detail targeted in those activities and their associated tasks, and the frequency and type of end user deliverables. The Project Workplan should be
developed from this core. The plan should then be scaled up, rather than tailored down, to the level of discipline appropriate to the identified risks and requirements. Even
at the task level, models and other outputs should be completed only to the level of detail required for them to be fit-for-purpose within the current iteration or, at the
project level, to suit the business needs of the enterprise and to align with the contractual obligations that govern the project.
OUM provides well defined templates for many of its tasks. Use of these templates is optional as determined by the context of the project. Task outputs can easily be a
model in a repository, a prototype, a checklist, a set of application code, or, in situations where a high degree of agility is necessary, simply the tacit knowledge contained
in the brain of an analyst or practitioner. For further reading on agility, see Balancing Agility and Discipline: A Guide for the Perplexed.
Risk-Focused
A key focus of each iteration in OUM is to attack and reduce the most significant project risks. This helps the project team address the most critical risks as early as
possible in the project lifecycle.
Why Use OUM?
More Focused Effort
OUM enables projects to clearly define business scope as well as the need to create architectural models of the enterprise. This planning results in tighter scope control,
more accurate business understanding, and a firm foundation to align with client expectations.
Built-In Flexibility
By combining activities and tasks in different ways, OUM can be applied to many types of information technology software development and implementation projects.
Saves Time
Seasoned information technology practitioners representing years of experience have contributed their knowledge to OUM. Project teams can take advantage of this
experience by leveraging these leading practices along with industry standards.
Higher Quality
OUM subscribes to an iterative approach that incorporates testing and validation throughout the lifecycle, rather than testing for quality only at the end of the project.
More Cost Effective
OUM facilitates improved control of project expenses by using a flexible work breakdown structure that allows you to perform only necessary tasks.
Reduce Project Risk
Implementing an iterative, broadly applicable method mitigates requirements mismatch. A key focus of each iteration in OUM is to identify and reduce the most significant
project risks. This allows for the most critical risks to be addressed as early as possible in the project lifecycle, which results in a measurable reduction of schedule and
budget risks.
Back to Top
KEY CONCEPTS
OUM has several key concepts and significant milestones that are used to manage the implementation cycle. These key concepts and milestones are demonstrated in the
Microsoft Project OUM Project Workplan. This example workplan provides a template for the partitions, phases, processes, milestones, and concepts used in an OUM
project.
This section provides a brief overview of the following concepts and significant milestones used to manage an OUM project:
Partitions
Iterations/Increments/Releases
Iteration Groups
Activities
Outputs
Partitions
The functionality that is targeted to be implemented within a project may be split into smaller pieces, known as partitions that are then implemented in parallel or serially
depending on project-specific factors. Partitioning is done to break down the complexity of a system, reduce risks, provide an earlier return on investment or business
value or inhibit scope creep on a project.
These partitions (sometimes also known as subsystems) may be implemented using the same approach or a different approach, depending on project-specific factors. A
partition is one defined part of the total functionality that will be developed in a project. If the functionality is split into partitions, then each partition is developed in a
number of iterations, or even as a separate OUM sub-project with its own set of OUM phases and iterations.
When defining partitions, it is important to consider the dependencies between the partitions. When splitting the total functionality into partitions, look for high cohesion
within a partition and low coupling between partitions.
Iterations/Increments/Releases
Projects based on OUM are carried out in an iterative fashion. Each iteration is concluded by the release of an executable product or set of artifacts, or both, that may be
a subset of the complete vision, but is useful from some engineering or user perspective. Iterations in the early phases of OUM typically produce project models or
documentation, though prototypes may also be involved. Iterations in the later phases of OUM typically produce working software, ready for test or production.
The OUM definition of an iteration is an increment. At the end of each iteration, the active set of outputs or artifacts are released to form the current baseline. A release is
therefore defined as a relatively complete and consistent set of artifacts possibly, but not necessarily including a software build delivered to an internal or external
user. An internal release is used only by the implementation organization, as part of a milestone, or for a demonstration to users. An external release is delivered to the
end users.
A release is not necessarily a complete product, but can just be one step along the way, with its usefulness measured only from an engineering perspective. Releases act
as a forcing function that drives the implementation team to get closure at regular intervals, avoiding the "90% done, 90% remaining" syndrome.
At each iteration, artifacts are updated and released. It is said that this is a bit like "growing" software. Instead of developing artifacts one after another in a pipeline
fashion, they are evolving across the cycle, although at different rates.
Iteration Groups
Iteration groups represent a subset of the requirements of a system or of a partition that have been grouped using four factors Risk, Complexity, Priority, and
Dependency. Iteration groups are then used to break down the work to allow it to be completed iteratively.
During analysis, we can and should break the requirements functionally into subsystems. However, a functional break down does not always provide the correct grouping
to define increments. It is preferable to define prioritized groups of functionality based on the factors mentioned above, so that the highest priority, riskiest, most complex,
etc. work is done early in a project.
Like partitioning, the circumstances on each project dictates the prioritization approach to be taken for the project. In some cases, the most complex items will be
developed first. In other cases, the team will decide to first implement functionality that demonstrates certain capabilities that require user feedback. In still other cases,
the iteration groups will be developed using some combination of these factors.
Activities
In OUM, tasks are grouped into Activities. Activities do not cross phases. They occur as a group of related tasks within the phase that result in the completion of a
substantial milestone or deliverable. Activities then are spread within the project phases according to the time and ordering where they occur during the life of the project.
One example would be all of the tasks that relate to gathering business requirements. Tasks from one process and one from another process are grouped into an Activity
called Gather Business Requirements.
Outputs
In OUM, the output of a task or activity is called a work product or simply output to eliminate the risk of having method deliverables confused with contractual deliverables.
Contractual deliverables are specifically referenced in the contract and often have a payment schedule associated with their acceptance. Contractual deliverables may be
method outputs, but they may also reference additional deliverables not documented by the method.
Not every task referenced in the method material is required for a given project. The required tasks are based on specific project scope. In this case, the "optional" tasks
are part of the OUM method material, but are not included in the Project Workplan.
Back to Top
CRITICAL SUCCESS FACTORS
Critical success factors may affect the selection of a project service. The following are typical critical success factors and their impact on the success of the
implementation
Project Size: OUM projects are most ideal for projects of less than 900 man-days. It is not a problem that the project is larger, but then you should consider
partitioning the project into a smaller projects each of less than 900 man-days.
Project Duration: OUM is built for rapid delivery of business benefits. Therefore, it is recommended that OUM projects have a duration of less than nine months.
Ideally, projects that initially need a longer duration for completion should be partitioned into a sequence of projects each of less than nine months duration.
Type of Organization: The organization culture can be of vital importance to the success of the project. Organizations with a lot of bureaucratic procedures and
work methods may not be able to participate and work using an OUM approach. Participants in an OUM approach must be able to make quick decisions that will
not be overruled on a higher organizational level. If you are planning to perform an OUM project in such an organization, make certain that the users involved in
the project are empowered to make decisions (within the project scope), that they are accepted by the rest of the organization, and that the users themselves feel
comfortable being in that role, taking on that responsibility and to making decisions (as they might not be used to doing exactly that).
Time-Critical Development: OUM is well suited for time critical development. However, if the end date easily can change, then many of the benefits of OUM will
be lost (for example, delivery of the highest prioritized use cases to quickly fit the business needs). If a fixed-end date is not critical for the business, it will still help
to agree on a fixed-end date as it aids control and motivation. It is a Manage task to hold on to this date and make the users understand the importance of keeping
the date fixed.
Availability and Commitment of Ambassador Users: OUM uses iterations as a basic principle of development and implementation; the ambassador users
provide input for determining the requirements as well as for verifying the end result of each iteration. Therefore, the project is dependent on the availability of well-
skilled ambassador users who must believe in the approach and this way of working, otherwise they may not prioritize their activities on the project. Ambassador
users must also be empowered to take decisions that affect the project. There is nothing more deleterious to progress on a project than to have the project
decisions require constant escalation and to have the authority of the ambassador users be undermined and countermanded.
Skilled Development Team: OUM is an approach with short delivery timescales where there is little time for learning on the job. Therefore, the project is more
dependent on the current skills of the team. If there is a lack of appropriate skills in the development team, at least one skilled resource should be included to
support the team. This resource time and effort must then be planned and estimated accordingly.
Visible User Interface: It is easier for the users to validate the result from the iterations through a user interface like a page or a screen. If the system being
developed does not have a visible user interface that covers a large portion of the software system, it will be necessary to find other means to validate the system
(for example, by showing flow diagrams, creating simulations of integration, etc.).
Baseline High-Level Requirements: OUM recognizes that requirements will change throughout the process, however, to be able to determine a well-defined
scope for the project, you need to be able to baseline the requirements on a high-level. If this is not possible, define the scope related to the Business and System
Objectives, but agree on a maximum effort that should be used to deliver a system related to these objectives.
Prioritizing of Requirements: To be able to deliver the most critical requirements first and to steer the development effort throughout the project, you need to
prioritize the requirements. It is important that the ambassador users understand this concept so that they realize the impact and importance of prioritizing at the
beginning as well as during the whole project.
Back to Top
REUSE STRATEGIES
Reuse is almost self-explanatory, and is a very simple but general concept and can be summed up as "not reinventing the wheel". All phases should make use of reusing
intellectual capital (IC). To make sure that Oracle is taking advantage of past projects and capturing the best from current projects, project and program managers should:
Plan and record reuse decisions and activities (Reuse Plan). If reuse is to be managed, it needs to be planned and monitored and therefore reuse intentions,
decisions, actions and results should be documented in a Reuse Plan. The Reuse Plan could either form part of the Quality Plan or be a separate document, as
appropriate. In either case, the Reuse Plan should be added to and amended during the course of the project and be reviewed during project reviews and in the
phase-end reports.
Create a task step for each task to assess whether there are assets which might be reused.
Perform a task to assess whether there is the possibility to package an aspect of the project for reuse.
Establish standards and guidelines for the generation of reusable assets and their reuse.
Make sure roles to monitor and manage reuse are part of the Project Workplan.
Potential Assets Assessment Task
Even though it makes sense to consider reusable assets during each task, it is probably more appropriate to create a task to evaluate any potential assets at the start and
end of each process or phase. The assessment of the reuse potential of assets in the phase or process should be recorded in the Reuse Plan. A proposal should be
created for reuse asset development (Reuse Packaging Proposal) for any candidate reuse assets that includes the following information:
a description of the asset to be packaged
the rationale for proposing the packaging of the asset
an estimate of the total effort and incremental effort involved in packaging the asset
The project reuse coordinator is responsible for executing this task as well as for developing the Reuse Packaging Proposal(s).
Reuse Standards and Guidelines
For an asset to be easily reusable, it must adhere to certain standards. Documents should adhere to a standard composition and make use of common elements and
project-specific variables. Code should adhere to the Oracle coding standards for the appropriate tool or language and perhaps fit into a technical or application
framework (for example, HeadStart for Applications). Some of these standards exist formally, but most exist informally or not at all. Each project will need to develop
these standards to make sure that assets are designed from the outset for maximum reuse
Back to Top
PUBLICATIONS AND WEBSITES
Please review the Bibliography page for further reading and information.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Focus Area Overview
Method Navigation Current Page Navigation
MANAGE
INTRODUCTION TO MANAGE (FORMERLY THE PROJECT MANAGEMENT METHOD-
PJM)
Any first attempt at converting folklore into knowledge, and a guessing game into a discipline, is liable to be misread as a downgrading of individual ability and its
replacement by a rule book. Any such attempt would be nonsense, of course. No book will ever make a wise man out of a donkey or a genius out of an incompetent.
The foundation in a discipline, however, gives to todays competent physician a capacity to perform well beyond that of the ablest doctor of a century ago, and enables
the outstanding physician of today to do what the medical genius of yesterday could hardly have dreamt of. No discipline can lengthen a mans arm. But it can lengthen
his reach by hoisting him on the shoulders of his predecessors. Knowledge organized in a discipline does a good deal for the merely competent; it endows him with
effectiveness. It does infinitely more for the truly able; it endows him with excellence.
From Managing for Results, by Peter F. Drucker
The Project Manager's Responsibilities
The fundamental responsibility of the project manager is to manage delivery of an agreed upon level of solution quality while planning for and controlling the "triple
constraints" (scope, cost and schedule). If a project is represented as a triangle, then the project manager's responsibility is to make sure that the target level of quality
is actualized while keeping the three sides of the triangle in balance.

Managing project scope, cost, schedule and quality is the primary objectives of a project manager. If any one of these components change, then the imbalance will result
in the change of one or more of the other components.
Managing the triple constraints to maintain an agreed to level of quality sounds fairly simple. Unfortunately, it is anything but simple. In No-Nonsense Advice for
Successful Projects, Management Concepts
17
, author Neal Whitten provides the following list of project manager responsibilities:
Directs the project as if it is his or her own business
Is fully accountable for the project
Applies lessons learned from past projects
Establishes well-defined project roles and responsibilities
Leads the project planning (Project Start Up) activities
Leads the project tracking and problem management activities
Promotes project management leading practices
Manages the project to an acceptable level of risk by balancing scope, time, cost and quality
Manages daily to the project's top three priorities
Empowers others: drives decision making to lowest level reasonable
Establishes the proper level of client involvement
Is a catalyst to resolve project problems and conflicts
Provides project status is timely communication to project stakeholders
Enforces effective change control
Promotes good working relationships
Makes things happen
The Manage focus area provides guidance to the project manager across all these responsibilities.
Back to Top
PHASES
The Manage focus area (formerly PJM) has three phases:
[A] Project Start Up Phase
[B] Project Execution and Control Phase
[C] Project Closure Phase
Each of these phases is intended to support the project manager during the traditional lifecycle phases of the project as well as to be easily used with an appropriate
execution method (specifically OUM Implement, however OUM Manage can be used with other execution methods).
[A] Project Start Up Phase
As implied by its name, the Project Start Up phase targets the beginning of the project. The goal of this phase is to conduct the necessary project start up. The project
manager will define the project with respect to scope, quality, time, and cost. The overall Project Management Plan and the plans for each Manage process will be
developed. The Project Start Up phase also includes establishing the project infrastructure and securing project resources.
[B] Project Execution and Control Phase
The Project Control and Execution phase is directly associated with the project lifecycle phases in OUM Implement (or another execution method). The purpose of this
phase is to manage the execution of the project. This includes using the policies, standards, and procedures delineated in the Project Start Up phase, and perform the
necessary reviews, and measurements to confirm that the project is being executed according to the published plan. It is also the process of comparing actual
performance with planned performance, analyzing variances, evaluating possible alternatives, and taking appropriate corrective action as needed. Corrective actions are
changes made to bring expected future performance of the project into line with the plan. The Project Execution and Control phase tasks are repeated for each execution
method lifecycle phase (for example, Inception, Elaboration, etc.).
Planning of each phase of the execution method is an integral step in the Project Execution and Control phase. The change in the organizational structure of the Manage
focus area does not eliminate the need to accomplish these tasks.
[C] Project Closure Phase
During the Project Closure phase, the project is "closed" from an administrative and contractual standpoint. This includes validating the project outputs are complete and
align with the organizations expectations, gaining final confirmation and securing all documents for reuse, collection and retention.
Integration with Implement Focus Area
The integration of Manage with Implement is illustrated below:
In general, the Manage Project Start Up phase is conducted prior to the first phase of the Implement focus area. The Manage Execution and Control phase runs
concurrently with the Implement focus area phases, and the Project Closure phase begins once the project execution is concluded.
Back to Top
ACTIVITIES
Manage tasks are further refined into activities to better represent the Project Management lifecycle.
Project Start Up Activities
Review Bid and Contract
Review Project Assets with Client
Validate Scope, Stakeholders, and Organization Change Management (OCM) Strategy
Develop Workplan
Develop Staff Plan and Budget
Complete Project Management Plan
Establish Project Infrastructure
Project Execution and Control Activities
The Project Execution and Control phase is made up of many ongoing tasks. An ongoing task is defined as a task that occurs continuously throughout a project, rather
than at a specific known time. The ongoing tasks occur as needed and do not include dependencies among the tasks or with the execution method tasks. The ongoing
tasks in Project Execution and Control are organized into the following activities:
Manage Scope, Acceptance and Approvals
Manage Project Finances
Manage Project Workplan
Manage Risks, Issues and Problems
Orient and Manage Team
Manage Communications and Organization Change Management (OCM) Plans
Manage Project Quality
Create and Execute Configuration and Release Management
Manage and Maintain Infrastructure
Administer Procurement of Goods and Contracted Services
Project Closure Activities
Gain Acceptance
Close Processes and Contract
Document Lessons Learned and Archive Project
In the Project Start Up and the Project Closure phases, there are dependencies among the activities which further define the Project Management lifecycle. The Project
Execution and Control phase is made up of ongoing tasks. In general, ongoing tasks are conducted as needed and not dependent on other tasks in the workplan.
Back to Top
PROCESSES
The Manage focus area is organized into thirteen (13) processes:.
Bid Transition
Scope Management
Financial Management
Work Management
Risk Management
Issue and Problem Management
Staff Management
Communication Management
Quality Management
Configuration Management
Infrastructure Management
Procurement Management
Organizational Change Management
The following diagram illustrates how the processes are executed across the three Manage phases.
Collectively, these processes form a comprehensive set of tasks required to manage an Information Technology project. Every project includes most, if not all, of these
processes, whether they are the responsibility of a consulting organization, a client organization, or a third party.
Relationships Among Manage Processes
There are many "touch points" among the Manage processes. In other words, the outcome or output(s) from one process often affect the output(s) of another process.
The relationships among processes in the Project Start Up phase illustrate this point. For example, Review and Analyze Bid Materials influences the Define and Confirm
Scope task of the Scope Management process which, in turn, influences development of the Project Workplan in the Work Management process which, in turn, helps
determine the Approved Project Budget and Financial Management Plan in the Financial Management process.
Another example of process relationships is stakeholder management. Preliminary stakeholder analysis begins in the Bid Transition process during Project Start
Up. Conducting stakeholder communications should be included as part of the Communications Plan developed in the Communications Management process and
this plan will be carried out during the Execution and Control phase. Additional stakeholder analysis and stakeholder alignment activities are also addressed as
appropriate in the Organizational Change Management process.
Back to Top
THE PROJECT MANAGEMENT PLAN
The Project Management Plan (PMP) is the single most important output produced by the project manager. It is initially created in the Project Start Up phase and
maintained throughout the project as needed.
The purpose of the Project Management Plan (PMP) is to define the overall project management strategies and approaches that will be applied to the project. The
Project Management Plan begins during Bid Transition with the creation of the Project Management Framework. The Project Management Framework is the first step in
addressing the components of the Project Management Plan at a high, strategic level. This document is created by the project manager in conjunction with the client. The
Project Management Framework is a prerequisite to creating the plans that support the thirteen Manage processes. The PMP is conceptual with its various components
made up of the thirteen plans of the Manage processes.
The PMP should not be a huge document. Rather it provides an overall project management roadmap (or framework) and should reference the detailed project
management process-level plans. Accordingly, where appropriate, the project manager should create a separate planning and management documents for individual
processes or process components. The Project Workplan, which is a major component of Work Management, should be maintained in the scheduling tool used on the
project (for example, MS Project) and not included in the overall PMP. The project manager should reference the location of the Project Workplan. The same approach
should be used for Financial Management, Risk Management, Issue Management, etc.
The figure below depicts the overall PMP and the process-level management plans that comprise it.
Back to Top
DELIVERABLE VS. WORK PRODUCT OR OUTPUT
The output of a Manage task is called a work product, or simply, an output. In past method releases, the output of a task was referred to as a deliverable. The term
deliverable has been changed to eliminate the risk of having the method deliverables confused with the contractual deliverables. A contractual deliverable is specifically
referenced in the contract and often has a payment schedule attached to its acceptance.
Contractual deliverables are typically method outputs, but they can also reference additional deliverables not documented in the method. In addition, not every task
referenced in the method material is required for a given project. The required tasks are based on specific project scope. In this case, the "optional" tasks are part of the
Manage method material, but are not included in the Project Workplan.
It is important for the project manager to understand and distinguish between these concepts in communications with clients.
Back to Top
SCALING MANAGE TO THE INDIVIDUAL PROJECT
Although it has been developed for moderate to large-scale projects, the Manage focus area is also applicable to smaller efforts as well. The philosophy behind Manage
is that the principles of sound project management, do not change with project size. Rather, the sophistication, structure and procedural approach should scale as
appropriate. For example, a large, multi-team, multi-site program will require a sophisticated Issue Management system and database while a small single location
project team may find a simple Excel spreadsheet sufficient for capturing and tracking issues. In line with this philosophy, each Manage task should be considered a
required, core task. However, the depth to which these tasks are performed on smaller projects may vary substantially from larger projects.
As part of scaling the Manage focus area to the project, the project manager must determine which, if any, Manage tasks should be expanded, reduced, or consolidated
based upon the scope, objectives, approach and risks of the project.
The Manage focus area is a scalable, flexible tool. It is comprised of well-defined processes that can be managed in several ways to guide a team through an
implementation project. Teams frequently tailor Manage to match the projects expertise, complexity, requirements and scope .
Note: Manage tasks within the processes, depending upon the scope, objectives and approach of the project, can be both linear and concurrent.
Back to Top
REUSE STRATEGIES
Reuse is almost self-explanatory, and is a very simple but general concept and can be summed up as "not reinventing the wheel." All phases should make use of reusing
intellectual capital (IC). To make sure that Oracle is taking advantage of past projects and capturing the best from current projects, project and program managers should:

Plan and record reuse decisions and activities (Reuse Plan). If reuse is to be managed, it needs to be planned and monitored and therefore reuse intentions,
decisions, actions and results should be documented in a Reuse Plan. The Reuse Plan could either form part of the Quality Plan or be a separate document, as
appropriate. In either case, the Reuse Plan should be added to and amended during the course of the project and be reviewed during project reviews and in the
phase-end reports.
Create a task step for each task to assess whether there are assets which might be reused.
Perform a task to assess whether there is the possibility to package an aspect of the project for reuse.
Establish standards and guidelines for the generation of reusable assets and their reuse.
Make sure roles to monitor and manage reuse are part of the Project Workplan.
Potential Assets Assessment Task
Even though it makes sense to consider reusable assets during each task, it is probably more appropriate to create a task to evaluate any potential assets at the start and
end of each process or phase. The assessment of the reuse potential of assets in the phase or process should be recorded in the Reuse Plan. A proposal should be
created for reuse asset development (Reuse Packaging Proposal) for any candidate reuse assets that includes the following information:
a description of the asset to be packaged
the rationale for proposing the packaging of the asset
an estimate of the total effort and incremental effort involved in packaging the asset
The project reuse coordinator is responsible for executing this task as well as for developing the Reuse Packaging Proposal(s).
Reuse Standards and Guidelines
For an asset to be easily reusable, it must adhere to certain standards. Documents should adhere to a standard composition and make use of common elements and
project-specific variables. Code should adhere to the Oracle coding standards for the appropriate tool or language and perhaps fit into a technical or application
framework (for example, HeadStart for Applications). Some of these standards exist formally, but most exist informally or not at all. Each project will need to develop
these standards to make sure that assets are designed from the outset for maximum reuse
Back to Top
PROJECT MANAGEMENT EFFORT
Estimating and organizing project management involves three factors:
Project Management Effort
Consulting-Client Relationship
Project Management Staffing
Oracles project experience indicates that total project management effort typically ranges from 15% of project effort for small projects to as much as 25% for the largest
projects. Project management effort increases as the project size increases because of increasing phase control complexity and coordination among full time project
management team members. Project duration also affects project management effort relative to total project effort, since Project Execution and Control occurs during the
entire project.
Back to Top
PROJECT DELIVERY ORGANIZATION
Consulting-Client Relationship
The people who have influence over the products and conduct of the project may be drawn from within the organization, supplied by an outside organization, or a
combination of both.
A contract may or may not be involved. In the Manage focus area, the consultant and the client represent the two parties which together form the project management
team responsible for the projects success. The client represents the customer organization, or primary beneficiary of the project, as well as the acquirer, or funding
source for the project. The client is also assumed to be capable of providing both physical and human resources for the project. The consultant represents an information
services provider organization with management structure and systems. This organization may be either a profit center, performing the project for a profit, or a cost
center, sharing project costs with the client. It is made up of practices, or business units that supply consulting staff resources and sub-contractors to the project. Note
that the tasks performed in reaching and maintaining a contractual agreement between the client and consultant are not covered in the Manage focus area. The Manage
focus area assumes that a contract may be established prior to the start of the project, and identifies where contractual impacts can occur during the project A contract is
not a prerequisite for the use of Manage. It also assumes that both the client and the consultant have internal management policies governing project conduct. Tailor
these aspects of the client-consultant relationship to your projects specific situation.
Key Project Management Roles
The key management roles performed by the client in the Manage focus area are the project sponsor and client project manager. The project sponsor is the client role that
holds the budget for the project, and may be an individual or a committee. The project sponsor establishes organizational commitment to the project and validates project
objectives. The client project manager is expected to be assigned to the project where client commitments or business interests require a daily client management
presence. This role is responsible for providing client resources, resolving problems, and monitoring the consultants progress. The key management roles performed by
the consultant in Manage are the consulting organization's (for example Oracle) project sponsor and the project manager. The consulting organization project sponsor
role represents the consulting manager whose practice is responsible for the successful execution of the project. The project manager is held ultimately responsible for
the projects success or failure. The project manager must manage the various aspects of time, cost, scope, and quality to align with client expectations and meet the
business objectives of the consulting practice, while providing challenging opportunities to project staff.
Back to Top
PROJECT MANAGEMENT STAFFING
The roles depicted in the organization chart are those that are assigned responsibilities to perform the Manage tasks.
Staffing involves two factors:
Role Allocated to Staff
Multi-Site Project Considerations
Roles Allocated to Staff
Each role defined in the project management support team will only be assigned to different people on medium-sized projects or larger. On the largest projects, there
may even be more than one person performing each of these roles, and the team will be organized into a project office, with a manager.
On smaller projects, the project manager assumes most of the responsibilities of the project support team. The first responsibility the project manager should relinquish as
project size increases is that of configuration manager. This role is frequently assigned to a senior person performing a technical support role, such as a system
administrator.
The responsibility for quality management is only a full-time position on large-scale projects. The quality auditor should not report to any of the project team due to a
potential conflict of interest. The quality auditor is a role independent of the project as shown on the staffing chart. There are other organizations that are commonly
employed on larger projects to facilitate management communication and decision-making:
Steering Committee
The steering committee represents the business objectives associated with the project, guides the overall project review, adopts the recommendations, and provides
sponsorship for implementing the changes. The steering committee includes high-level stakeholders, along with the project sponsor. Regular meetings should be held to
review progress and resolve outstanding issues. The steering committee members are responsible for the project approach buy-in, funding, issue resolution, and sign-off.
Change Control Board (CCB)
The CCB is an internal, formally chartered project organization responsible for reviewing, evaluating, approving, delaying, or rejecting change requests, and for recording
and communicating such decisions. The CCB is chaired by the project manager and includes the client project manager, project administrator, configuration manager,
and team leaders. The CCB normally escalates changes affecting scope to the steering committee.
Issue Review Board (IRB)
The IRB is organized to review and provide recommendations in order to address escalated issues and risks in situations where a regular, dedicated meeting is deemed
necessary. It is staffed similarly to the Change Control Board (CCB), and can be combined with it. It may also be part of a weekly project progress review team that would
meet to discuss project progress as well as issues and risks.
Multi-Site Project Considerations
Multiple site projects require a higher level of project administration and control to coordinate the tasks and to leverage common outputs between projects. In a multiple
site project, you will need to position site coordinators as part of your project management team. These people also establish consistency in the delivery and
presentations of work, use of techniques and approach, use of standards and guidelines, and interpretation of enterprise-wide strategies.
Another important role that coordinators perform is facilitating the technical strategies between related sites. This role calls for a more formal exchange of technical
information and status review. These site coordinators will also distribute software and documentation to multiple data centers.
Back to Top
MANAGEMENT
Please read Project Management in OUM. It describes how the OUM Manage focus area and Implement focus area work together.
If you have never managed a project with a Unified Process approach, or are not familiar with the terms "iterative" or "incremental, read the Tips for Project Managers and
Planning a Project using the Oracle Unified Method (OUM). For further information on managing iterative projects, see Managing Iterative Software Development
Projects.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[PS] PROJECT START UP
The purpose of the Project Start Up phase is to provide strong and clear directions for producing a product or service which delivers identified benefits or purpose for the
business. During the Project Start Up phase, resources are allocated to accomplish specific objectives, satisfy needs, and set expectations through a planned and
organized approach.
A key output of the Project Start Up phase, the Project Management Plan, provides the necessary objectives, strategies, plans, methods, tools, resources and procedures
to achieve the expected benefits or purpose in the business. The Project Start Up phase is considered the most important phase in the project. The tasks within the
Project Execution and Control phase are built on the foundation established in Project Start Up.
There must be a strong commitment to perform the project from the business and the prime supplier. A forum should be established to share the project's status, risks and
issues with the key stakeholders and obtain feedback.
The following lists contains prerequisites that must exist in the project organization in order to deliver the solution completely and satisfactorily. These prerequisites must
be in place prior to the Project Execution and Control phase.
Funding of the project is documented and signed-off
Statement of the work is documented and signed-off
Required financial approvals achieved
Required resources received
When subcontracting, subcontractor agreement is documented and signed-off
Project planning is completed
Infrastructure is established
Required project training is prepared
Project team orientation is prepared
Project control-cycle is developed and documented including tracking and taking corrective actions
Configuration Management and scope change procedures are developed
Quality Management including project acceptance procedures are developed
Back to Top
OBJECTIVES
The following is a list Project Start Up phase objectives:
Objectives, needs and expectations allocated to the project are documented, controlled, and baselined for project planning and control.
Project plans, work products, and tasks are kept consistent with the agreed upon objectives, needs and expectations allocated to the project.
Project estimates are documented for use in planning and control of the project.
The prime contractor selects and secure qualified subcontractors and resources.
The prime contractor and the subcontractor agree to their commitments to each other.
Affected parties agree to their commitment related to the project.
Quality assurance tasks are planned.
Configuration management tasks are planned.
Project infrastructure is established.
Project acceptance procedure and criteria is documented and agreed between parties.
Project control cycle is documented and approved between parties.
Project training and project orientation is prepared.
Obtain sponsors approval to proceed.
Back to Top
PROCESSES
The Manage context diagram illustrates the processes within the Project Start Up phase.
Back to Top
TIPS AND TECHNIQUES
Best practice suggests the key Project Start Up activities are shown on the project plan. These activities are generally short term, lasting no longer than four to six weeks
even on the largest of projects.
The level of granularity of Project Start Up tasks shown on the Gantt chart cannot be prescribed. This level depends on many factors. Factors include the role of all
involved during Project Start Up and the size and complexity of the project. It is recommended that key activities arising from Project Start Up are shown as discrete tasks
on the Gantt chart.
See the Manage example workplan (in MS Project) for an example of the Project Start Up activities and sequence.
An objective of the Project Start Up phase is to understand and influence the expectations of key project stakeholders. Document and communicate your vision of the
project to the Project Sponsor, key stakeholders, management, and the project team. Evaluate the project proposal as your starting point for Project Start Up. How have
expectations been set? Have there been changes since the project proposal was accepted?
Set Expectations Early
The initial scoping in the Project Start Up phase covers all areas of known risk, working policies, agreed approaches, communication, and implementation strategies.
Original project proposals or Project Charter may already include some of these topics. However, in creating the original project proposal, assumptions may have been
used. During Project Start Up, you must verify all the documented and undocumented assumptions.
Note: The main objective of the Project Start Up phase is to prepare the Project Management Plan. To conduct the project without the Project Management Plan, you risk
not having a point of reference for change control, and must rely heavily on verbal commitments, which can often lead to serious misunderstandings and disputes about
what was agreed to.
In some cases, clarification and justification may be needed before approving work products. The Project Management Plan can be used to explain why certain methods,
approaches, and techniques were used. If organized correctly it can serve as the vehicle for justifying why and how project tasks are being performed. Within this context,
the planning for reuse should be established to increase productivity and reduce costs as well as risks. Reuse of work products will help to reduce the risk of the project
since these provide actual examples of previous project work.
The following illustrates the key project management components of the Project Management Plan
Obtain Initial Approvals
Arrange for a review with key stakeholders, if possible upon starting the project. The purpose of the review is to determine the overall health of a project and its prospects
for success, check the completeness of plans, and ensure a clear understanding of project control and completion procedures.
Suggestion: Use start up meetings to communicate the plans to the project stakeholders. Consider separate meetings for management and project staff. A formal
presentation should be delivered to the project sponsor, as a minimum.
The primary techniques you use in this process during Project Start Up are stakeholder analysis, risk assessment, interviewing, negotiation, and presentation. Use these
techniques to discover and cater to all factors which could ultimately jeopardize the projects success.
Scrum
If you are using a Scrum approach, use the Managing an OUM Project using Scrum technique. Use this link to access the phase-specific guidance for Scrum.
Back to Top
TASKS AND WORK PRODUCTS
This phase includes the following tasks:
ID Task Work Product Key Type
Review Bid and Contract
BT.010 Review and Analyze Bid Material Reviewed Bid Material Core
BT.020 Review and Confirm Business Case Reviewed Business Case Core
BT.030 Identify Project Stakeholders Identified Project Stakeholders Core
BT.040 Review and Accept Project Budget Accepted Project Budget Core
RKM.020 Conduct Baseline Risk Assessment Baseline Risk Assessment Y Core
Review Project Assets with Client
BT.050 Review Contract with Client Reviewed Contract Y Core
BT.060 Review Project Approach with Client Reviewed Project Approach Y Core
BT.070 Create Project Management Framework Project Management Framework Y Core
Validate Scope, Stakeholders and OCM Strategy
SM.010 Define and Confirm Scope Validated Scope Y Core
CMM.010 Conduct Project Stakeholder Analysis Project Stakeholder Analysis Core
OCHM.010 Understand Client's Organization Change Management Strategy
Understanding of Client's Organization Change Management
Strategy
Y Core
Develop Workplan
WM.010 Develop Baseline Project Workplan Baseline Project Workplan Y Core
Develop Staff Plan and Budget
FM.010 Refine Project Budget Approved Project Budget Y Core
STM.010 Plan Resource Requirements Resource Requirements Core
STM.030 Staff the Project Staffed Project Y Core
STM.040 Prepare Project Orientation Guide Project Orientation Guide Core
Complete Project Management Plan
SM.020 Develop Scope Change Management Processes Scope Change Management Processes Y Core
FM.020 Develop Financial Management Plan Financial Management Plan Y Core
WM.020
Develop Work Management Execution and Control Processes and
Policies
Work Management Plan Y Core
RKM.010 Develop Risk Management Plan Risk Management Plan Y Core
IPM.010 Develop Issue Management Strategy Issue Management Strategy Y Core
IPM.020 Develop Problem Management Strategy Problem Management Strategy Y Core
STM.020 Develop Staff Management Plan Staff Management Plan Y Core
CMM.020 Develop Project Team Communication Plan Project Team Communication Plan Y Core
QM.010 Develop Quality Management Plan Quality Management Plan Y Core
QM.020 Develop and Document Quality Control and Reporting Process Quality Control and Reporting Process Core
CM.010 Develop Configuration Management Strategy and Processes Configuration Management Strategy and Processes Y Core
CM.030 Create Project Documentation Management Plan Documentation Management Plan Core
IFM.010 Develop Infrastructure Management Plan Infrastructure Management Plan Y Core
PCM.010 Develop Procurement Strategy and Process Procurement Strategy and Process Y Core
OCHM.020 Identify Change Management Warning Signs Change Management Warning Signs Core
Establish Project Infrastructure
FM.030 Set up Time and Expense Tracking Time and Expense Tracking Core
RKM.030 Develop Risk Management System Risk Management System Core
IPM.030 Develop Issue and Problem Management System Issue and Problem Management System Core
CM.020 Obtain Configuration Management Tools Configuration Management Tools Core
IFM.020 Establish Team Work Environment Established Team Work Environment Core
IFM.030 Establish Technical Infrastructure Established Technical Infrastructure Core
PCM.020 Procure Goods and Contracted Services Service Orders Core
Back to Top
ACTIVITY FLOW DIAGRAM

Back to Top
RISK MANAGEMENT
The most likely areas of risk during Project Start Up are the following:
External
Lacking of project sponsor
Insufficient resources available
Interfaces between projects not considered
The facilities are not conductive for project work
Management
Low management attention, or management does not hold the project team accountable
Missing contingency
Planning
Unclear objectives
Unclear scope and work products
Insufficient number of milestones
Plan is too informal
Not an appropriate project organization
Adequate control cycle is not developed
Resources
Anticipated resources fail to appear
No organized approach for sharing information
Methods and Tools
Employing different, incompatible tools
Back to Top
CRITICAL SUCCESS FACTORS
These factors have been shown to be critical to the success of this phase:
The business objectives, scope and work products are understood by the project team and documented in the Project Management Plan.
There is a committed project sponsor from the organization who makes sure that other members of the company share this commitment to the project.
Effective hand over of the engagement from the bid manager.
The necessary resources have been identified and committed to the project in order to complete it within the planned time frame.
A realistic and achievable project and financial plan has been developed including all project activities, tasks and resources.
Project infrastructure is completely and correctly implemented before the majority of the project team are on site.
The project plan and procedures have been communicated to the organization and project team and are well understood by all.
The project team provides input to the project workplan and is committed to the success of the workplan.
There is committed sponsorship for the project.
Risk assessment has been completed with plans for mitigation.
Change control is implemented.
Configuration management has been implemented.
Expectations have been discussed, understood, and the management of expectations is part of the Project Team Communication Plan.
Scope, objectives, and approach are agreed on and understood by all parties.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.RBC - REVIEW BID AND CONTRACT
This activity is the first activity that the project manager will conduct after being assigned to the project. This activity bridges the gap between the Bid Preparation process
and Project Start Up.
Back to Top
OBJECTIVES
The objective of this activity is to have the project manager accept "ownership" of the project.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
BT.010 Review and Analyze Bid Material Reviewed and Analyzed Bid Management Reviewed and Analyzed Bid Material
BT.020 Review and Confirm Business Case Confirmed Business Case Confirmed Business Case
BT.030 Identify Project Stakeholders Identified Project Stakeholders Identified Project Stakeholders
BT.040 Review and Accept Project Budget Accepted Project Budget Refer to the Task Overview for guidance.
RKM.020 Conduct Baseline Risk Assessment Baseline Risk Assessment Baseline Risk Assessment
Risk Mitigation
Back to Top
ITERATIONS
This activity is conducted as the first step in the Project Start Up phase.
Back to Top
APPROACH
The approach to this activity is:
Review bid material.
Gain background information from bid team and sales team.
Identify the project stakeholders.
Conduct a Baseline Risk Assessment for the project.
Back to Top
PREREQUISITES
You will need the following for this activity:
Bid Material
Contract
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.RPAC - REVIEW PROJECT ASSETS WITH CLIENT
This activity finalizes the gap between the Bid Preparation process and Project Start Up.
Back to Top
OBJECTIVES
The objective of this activity is to review the contract and project approach with the client and create the framework for the Project Management Plan. This includes
making any necessary updates to the contract and project approach prior to the project kickoff.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
BT.050 Review Contract with Client Reviewed Contract Reviewed Contract
BT.060 Review Project Approach with Client Reviewed Project Approach Reviewed Project Approach
BT.070 Create Project Management Framework Project Management Framework Project Management Framework
Back to Top
ITERATIONS
The individual tasks should be iterated until approval is achieved.
Back to Top
APPROACH
The approach to this activity is:
Review contract and project approach.
Adjust contract and project approach as appropriate and gain necessary approvals.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.RBC Review Bid and Contract
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.VSSOS - VALIDATE SCOPE, STAKEHOLDERS AND
ORGANIZATIONAL CHANGE MANAGEMENT (OCM) STRATEGY
This activity occurs after the bid and contract have been reviewed with and approved by the client. Then the next key activity for the project manager is to validate the
scope.
The project manager will also conduct the project stakeholder analysis. Having an understanding of the project stakeholders and understanding the organizational change
management strategy are important steps that play a key role in creating the Communication Plan and understanding the communication needs of the project.
Back to Top
OBJECTIVES
The objective of this activity is to have a clear understanding of the project scope. In addition, understanding stakeholders and OCM strategy will both help to further
define the scope and will be a key input into the communication plan.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
SM.010 Define and Confirm Scope Validated Scope Validated Scope
CMM.010 Conduct Project Stakeholder Analysis Project Stakeholder Analysis Project Stakeholder Analysis
OCHM.010 Understand Client's Organizational Change
Management Strategy
Client's Organizational Change Management
Strategy
Client's Organizational Change Management
Strategy
Back to Top
ITERATIONS
This activity is conducted once.
Back to Top
APPROACH
The approach to this activity is to:
Clearly identify all application modules, enhancements, reports, interfaces, conversions and locations in scope.
Define what is out-of-scope.
Define key project assumptions as part of the scope definition.
Define how much contingency (i.e., management reserve is going to be withheld for risk, issues, problems, and unplanned work).
Document all assumptions concerning scope, resources, user participation, sign-off, issues resolution, QA.
Ensure that the concerns of key stakeholders are addressed and that the efforts of these stakeholders are aligned with the project's business objectives.
Clarify the scope of the project Organizational Change Management work with the client.
Back to Top
PREREQUISITES
You will need the following for this activity:
Bid Material
PS.ACT.RBC Review Bid and Contract
PS.ACT.RPAC Review Project Assets with Client
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.DW - DEVELOP WORKPLAN
The project manager creates a complete, detailed Project Workplan. The Project Workplan denotes all the tasks and activities to be performed by the team within the
projects scope, objectives, and approach and should align directly to the governance approach as described in the Project Management Plan (PMP). It should include
client activities that are dependencies for project success (including Configuration, Infrastructure Management, Communications, Organizational Change Management
and Training). The Baseline Project Workplan should include a detailed (task-level) workplan for the current iteration with a high-level (activity-level) workplan for the
remainder of the project.
Back to Top
OBJECTIVES
The objective of this activity is to create a complete, detailed workplan.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
WM.010 Develop Baseline Project Workplan Baseline Project Workplan Implementation Plan
Iteration Plan Summary
Refer to Appropriate View Example Project Workplan
Back to Top
ITERATIONS
This activity is conducted in conjunction with the Develop Staff Plan and Budget activity. Both activities are iterated until a detailed Baseline Project Workplan is created.
Back to Top
APPROACH
The approach to this activity is to:
The workplan is verified against the contract and the Validated Scope. Keep in mind that any changes to the WBS must be approved by both the client and the
business line.
Decompose workplan to the lowest level of activity.
Develop task level estimates.
Sequence activities and tasks.
Assign and level resources.
Refine and baseline the workplan.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.VSSOS Validate Scope, Stakeholders and OCM Strategy
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.DSPB - DEVELOP STAFF PLAN AND BUDGET
This activity is conducted in conjunction with the Develop Workplan activity. Using the workplan as input, the project manager develops the staff plan and the project
budget. In addition, orientation guides are prepared in order to prepare for the project kickoff.
Back to Top
OBJECTIVES
The objective of this activity is to create a staff plan and a project budget and prepare the orientation guides for project kickoff.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
FM.010 Refine Project Budget Approved Project Budget Refer to the Task Overview for guidance.
STM.010 Plan Resource Requirements Resource Plan Project Team Organization Chart
Resource Plan
STM.030 Staff Project Staffed Project Refer to the Task Overview for guidance.
STM.040 Prepare Orientation Guide Orientation Guide Project Orientation Guide
Back to Top
ITERATIONS
This activity is conducted in conjunction with the Develop Workplan activity. Both activities will be iterated until a staff plan and budget is created.
Back to Top
APPROACH
The approach to this activity is to:
Obtain and apply the rates to derive the labor budget that relates to the planned effort and resources required to perform the project.
Calculate a project non-labor expense budget.
Validate the budget.
Cost burden the workplan
Verify that project is funded properly (labor and expenses) in the relevant company financial systems.
Verify that services invoicing processes are in place for the service provider, client and sub-contractors.
Develop and agree to a policy for use of non-billable codes.
Define labor and expense tasks for recording actuals in accordance with project requirements and procedures.
Work with operations to set up labor tasks.
Identify, document, and assign roles, responsibilities, and reporting relationships for the project team members.
Prepare Orientation Guides.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.VSSOS Validate Scope, Stakeholders and OCM Strategy
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.CPMP - COMPLETE PROJECT MANAGEMENT PLAN
This activity prepares the key plans that are used to manage the project. The Project Management Framework, created as part of the Review Project Assets with Client
activity, created the initial, high-level view or framework of the Project Management Plan (PMP). This activity takes each of the Project Management Plan components
and provides the necessary details. The PMP is a conceptual work product with its various components made up of the thirteen plans of the Manage processes cataloged
within the Project Management Framework.
The purpose of the Project Management Plan (PMP) is to verify and confirm the projects scope and then to define the governance approach to project management by
identifying how the critical, strategic areas of the project will be planned, executed and controlled, and monitored and reported on. Project scope needs to be validated
and specified in detail. This is especially critical where the scope has been vaguely written into the contract. Important background information such as related source-of-
authority documents, project objectives, and critical success factors should be documented.
This activity takes each component of the Project Management Framework and provides necessary details on key plans for managing the project, such as the Change
Control process. This activity is conducted in conjunction with the Develop Workplan, Develop Staff Plan and Budget and Establish Project Infrastructure activities.
It is not necessary to include detailed planning/process documents focused on normal implementation activities and doing so may reduce the effectiveness of the
document by making it unreadable. The PMP, itself, should not be a huge document. Rather it provides an overall project management roadmap or framework and
should reference the detailed project management process-level plans. Accordingly, where appropriate, the project manager should create a separate planning and
management document(s) for individual processes or process components. For example, your Project Workplan, which is a major component of Work Management
should be managed in the scheduling tool used on the project (e.g., MS Project) and not cut and pasted into the overall PMP. In the overall PMP, the project manager
should reference the location of the Project Workplan, key workplan maintenance standards, and responsibilities for its maintenance. The same approach should be
used for Financial Management, Risk Management, Issue Management, etc.
The PMP is a living document that is updated periodically as key changes in the project occur.
Back to Top
OBJECTIVES
The objective of this activity is to complete the Project Management Plan to use as a baseline for executing and controlling the project.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
SM.020 Develop Scope Change Management Processes Scope Change Management
Processes
Scope Change Management Process
Scope Change Management Checklist
FM.020 Develop Financial Management Plan Financial Management Plan Financial Management Plan
WM.020 Develop Work Management Execution and Control
Processes and Policies
Work Management Plan Work Management Execution and Control Processes
and Policies
RKM.010 Develop Risk Management Plan Risk Management Plan Risk Management Plan
IPM.010 Develop Issue Management Strategy Issue Management Strategy Issue Management Strategy
IPM.020 Develop Problem Management Strategy Problem Management Strategy Problem Management Strategy
STM.020 Develop Staff Management Plan Staff Management Plan Staff Management Plan
Staff Training Plan
Staff Management Procedures
Project Roles and Responsibilities Presentation
CMM.020 Develop Project Team Communication Plan Project Team Communication Plan Project Team Communication Plan
Client Profile
Steering Committee Presentation
QM.010 Develop Quality Management Plan Quality Management Plan Quality Management Plan
Quality Management Procedures (Generic)
Quality Management Procedures (Modified for OUM)
QM.020 Develop and Document Quality Control and Reporting
Process
Quality Control and Reporting Process Quality Control and Reporting Process
Quality Control Checklist
Quality Review Report (Generic)
Quality Review Report (Modified for OUM)
CM.010 Develop Configuration Management Strategy and
Processes
Configuration Management Plan and
Processes
Configuration Management Plan and Processes
Configuration Management Procedures
Configuration Item Index
Configuration Item Status Record
CM.030 Create Project Documentation Management Plan Documentation Management Plan Documentation Management Plan
Document Index-Word
Document Index-Excel
Document Update Notice
IFM.010 Develop Infrastructure Management Plan Infrastructure Management Plan Infrastructure Management Plan
Installation Plan and Record
PCM.010 Develop Procurement Strategy and Process Procurement Strategy and Process Procurement Strategy and Process
OCHM.020 Identify Change Management Warning Signs Change Management Warning Signs Change Management Warning Signs
Back to Top
ITERATIONS
This activity is iterated until all of the Project Management Plan components have been completed and signed-off by the client.
Back to Top
APPROACH
The approach to this activity is to:
Develop Scope Change Management Processes
Develop Financial Management Plan.
Develop Work Management and Execution and Control Processes and Policies.
Develop Risk Management Plan.
Develop Issue Management Strategy.
Develop Problem Management Strategy.
Develop Staff Management Plan.
Develop Project Team Communication Plan.
Identify which quality standards are relevant to the project and determine how to satisfy them.
Develop and Document Quality Control and Reporting Process.
Develop Configuration Management Strategy and Process.
Create Project Documentation Management Plan.
Develop Infrastructure Management Plan.
Develop Procurement Strategy and Process.
Identify Change Management Warning Signs.
Ensure that the Project Management Plan is straight to the point, avoid boilerplate text and keep it as concise as possible it has little value if it is unreadable. Consider
putting standard text or excessive detail in separate documents, e.g., procedures or using a summary-level presentation.
PREREQUISITES
You will need the following for this activity:
PS.ACT.RPAC Review Project Assets with Client
PS.ACT.DW Develop Workplan
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PS.ACT.EPI - ESTABLISH PROJECT INFRASTRUCTURE
This activity sets up the system and tools needed to conduct the project.
Back to Top
OBJECTIVES
The objective of this activity is to set up the technical and environmental infrastructure for the project. The Project Management Plan will determine the appropriate tools,
systems, and technical and environmental infrastructure to be used on the project.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
FM.030 Set Up Time and Expense Tracking Time and Expense Tracking Expense Tracking Spreadsheet
Project Team Time Sheet
RKM.030 Develop Risk Management System Risk Management System Risk Form
Risk Log
Risk/Issue/Problem Log
IPM.030 Develop Issue and Problem Management System Issue and Problem Management System Issue Form
Issue Log
Problem Form
Problem Log
Risk/Issue/Problem Log
CM.020 Obtain Configuration Management Tools Configuration Management Tools Refer to the Task Overview for guidance.
IFM.020 Establish Team Work Environment Team Work Environment Refer to the Task Overview for guidance.
IFM.030 Establish Technical Infrastructure Established Technical Infrastructure Physical Resource Plan
PCM.020 Procure Goods and Contracted Services Service Orders Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
This activity is iterated once.
Back to Top
APPROACH
The approach to this activity is to:
Set up Time and Expense System.
Develop Risk Management System.
Develop Issue and Problem Management System.
Obtain Configuration Management Tools.
Establish Technical Infrastructure.
Establish Team Work Environment.
Procure Goods and Contracted Services.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.DW Develop Workplan
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[PEC] PROJECT EXECUTION AND CONTROL
The purpose of the Project Execution and Control Phase is to provide adequate visibility into actual progress so that management can take effective actions when the project's
performance deviates significantly from the project plans.
The Project Execution and Control Phase includes tracking and reviewing the projects accomplishments and results against documented WBS-dictionary, project estimates, time
schedule, resources plan and cost budget, and adjusting these plans based on the actual accomplishment and results.
To be able to perform this phase, the following must be in place:
All work products agreed with the organization must be identified and documented in a WBS-dictionary.
The development time schedule for the project must be documented and approved.
The project manager explicitly assigns responsibilities for the necessary work.
Adequate resources and funding are provided for execution and control of the project.
A cost control cycle, preferably based on 'earned value' concepts is developed.
The project management team is experienced/trained in managing the technical and personnel aspects of the project.
The project management team has received orientation in the technical aspects of the project.
Project structuring is the basis for good project control. Structuring the project into several dimensions provides the framework for project control. For example several dimensions
can combine WBS-elements with project organization elements and cost elements. The intersection of these dimensions and a time schedule is essential to effective project
management.
Back to Top
OBJECTIVES
The following is a list of the objectives of this phase:
Track project performance against the Project Workplan.
Monitor and control project work by taking corrective action and managing to closure when actual results and performances deviate significantly from the Project Workplan.
Communicate all changes to project commitments by documenting and obtaining agreement by the affected parties.
Maintain ongoing communication with all parties.
Track subcontractor's actual results and performance against its commitments (when a subcontractor is used).
Objectively verify adherence of work products and tasks to the applicable standards, procedures, and requirements. Noncompliance issues that cannot be resolved within
the project are addressed by senior management.
Inform affected parties of quality assurance tasks and results.
Perform configuration management on identified work products.
Manage and control changes to identified work products.
Communicate status and content of project baselines to all affected parties.
Provide the mechanisms to enable the project team to function in a proactive mode.
Anticipate possible risks and issues to the project and take preventive measures to contain them.
Consistently promotes and employs the policies, standards and procedures for the capture and reuse of project intellectual capital.
Back to Top
PROCESSES
The Manage focus area context diagram illustrates the processes within the Project Execution and Control phase.
Back to Top
TIPS AND TECHNIQUES
Best practice suggests the key Project Execution and Control tasks should be shown on the Project Workplan. While these tasks are generally short in duration, many will recur
during each phase of the execution method, e.g., OUM, AIM, Compass.
The level of granularity of the Project Execution and Control tasks shown on the Gantt chart cannot be prescribed. This depends on many factors. Factors may include the role of
consulting during project execution and the size and complexity of the project.
This section discusses techniques that may be helpful in conducting Project Execution and Control phase.
Monitoring and Reporting
Tasks are managed in this process to control the direction of the project and maintain a solid partnership with the implementing organization and the business. The key
techniques you employ during Project Execution and Control phase are leadership, communication, motivation, conflict management, analysis, and risk/issue resolution.
Monitor and Report Progress Regularly
One of the most critical activities during Project Execution and Control phase is monitoring and reporting. If properly employed, the regular progress reporting and review cycles
can provide a solid forum from which you can stay in control of project work. You will receive and create a wealth of qualitative and quantitative information in these reviews to
help you and your project leaders find issues/risks and fix them before they become uncontrollable.
Attention: The following are suggested management reviews for your project. Make sure that you distinguish between these and project technical reviews, such as design
reviews, by controlling the attendance, contributions, and agenda of the meetings. For example, a progress review attended by many users can turn into a design review if not
controlled.
Team Progress Reviews. You will need to determine who comprises the "team". It could be the group of people in one organizational leg in the project organization, or it
could consist of all team leaders on the project.
Team Progress Reviews should be held on a weekly basis to assess the progress of each team and to plan for the following week or weeks. They also include a discussion
of any changes, issues/risks, problems and lessons learned. Workplans and resource plans are updated in preparation for the Team Progress Review based on
completion of timesheets by staff. The meeting should be chaired by the project manager or a team leader on the specific team.
Weekly Project Progress Reviews could be without any financial implications i.e. a review where schedule performance and effort (hours) performance is communicated
compared to baselines, included changes and the resource situation. Managing risks and issues should be the main objective in the meeting. This meeting could be held
on weekly bases and based on team reports and team members weekly time reports.
Monthly Project Progress Reviews are normally held at monthly intervals, covering each financial reporting month. A report is given by the project manager to
management, summarizing project performance (including financial status), risks/issues and relationship. Current project status prepared by the project manager will be a
key input to the meeting.
Steering Committee Meeting. The project steering committee meets at an interval usually determined by the project sponsor to review the progress of the project and
discuss business issues relevant to the project. The implementing organization and business project managers represent the project at these meetings.
Note: Never be pressured into changing estimates or direction during a review meeting. Take time away from the meeting environment to make a decision.
The success of your project depends on a good level of communication within your project team. You must facilitate and encourage good communication by constant concern and
effort. No amount of formal review can substitute for spending time informally chatting with your project members, and walking around your project work area. You will gain
invaluable information about individuals, their work, and rate of progress. You will also be able to pick up on personal or political problems that can impede or are already
affecting project work.
Suggestion: The qualitative information you gain, along with your own experience, should be used to corroborate the quantitative information in your project reviews. You need to
feel satisfied that the figures are telling you the same thing as your impressions when you present your own progress reports.
Control the Workplan
The Work Management Control and Financial Management Control activities are usually synchronized with the status monitoring and reporting activities but they can have
different structures. Project Execution and Control phase techniques you employ in Work Management will be a combination of those used during planning, plus performance
measurement and variance analysis.
Keep the Workplan Realistic
Project manager or an assigned resource control the work progress against the workplan for the phase by iterating through a regular tracking cycle which results in a comparison
of actual progress to workplan. You follow up by directing replanning to adjust the workplan to reality where necessary, and by assigning corrective actions to bring future
performance in conformance with the Workplan.
Warning: Watch for the following pitfalls when performing Workplan Control:
Too much replanning, insistence on a perfect workplan inconsistent with the way the project is being controlled
workplan too general or too detailed to be useful for control stretching the planning baseline to match results
Project activity, but not enough tasks being completed to permit assessment of progress management tasks on the critical path
Task effort on workplan differs from the real assignment in a resource plan. Resources cannot be thrown out if they do not have tasks for few days. This means that the
resource plan should be updated as well with actuals to have a safe approach forward
Good workplan control begins with a workplan against which project members can accurately charge their time at the task level. Each project member should submit a time
record, either in the planning tool or on a separate worksheet, once each week. The total hours recorded against the project should add up to the number of hours charged to the
project in the project accounting system.
Suggestion: Encourage project members to keep an ongoing record during the week of how they spent their time, rather than waiting until the day the time record is due.
Using Earned Value Analysis
Earned value analysis is a technique which is commonly used to add objectivity to financial performance measurement. Earned value method can be used with only hours, days
etc. When you use earned value analysis, your project budget, actuals, and estimates-to-complete are tied closely to project work products giving you a more realistic view of
project work. Earned value analysis involves calculating the value of a work product at a particular point in time, based on the budget and rules that define when the value of a
work product is earned. You use the earned value, budget, actuals, and estimates-to-complete to provide indicators of whether or not work is being accomplished as planned.
Staff Management
During the Project Execution and Control phase, you manage the staff and infrastructure you have already put in place to ensure that your project can efficiently accomplish the
assigned tasks. The techniques you will use most frequently during Staff Management deal with your project staff. In addition to the planning techniques you use to adjust your
project organization, you will need to apply performance management, team building, motivation, leadership, and conflict management skills.
Actively Monitor Your Resources
Repeat the exercise of going through your workplan to check which physical resources will be needed at frequent intervals. As you progress through the phase, you learn more
about it, and better identify your critical resource needs. Keep careful watch over tasks that depend on a resource supplied by the business or a vendor in order to begin. Put
these tasks and milestones on your Workplan to help you monitor them with the client project manager. Act decisively if a project member cites the lack of a physical resource as
the reason for not completing a task on time.
Suggestion: Identify the person responsible for the resource and hold them to their commitment. Ensure that the person actually understands the need and is willing and able to
provide you with the goods and services you expect. Be prepared to encounter dramatic examples of bureaucracy. It can require skillful negotiating and tenacity to acquire or
control things over which you may have no direct authority.
Be a People Manager
As the project manager, the way you utilize your staff will have a profound impact on your project, as well as influencing their professional development. There is a substantial and
dynamic body of knowledge on building, motivating, and leading project teams. Keeping current on these techniques should be a key focus area of your own professional
development.
Suggestion: Do not forget yourself and your project management staff when you plan training for your project. Schedule management training or directed team building sessions
using current training offerings available to you, either internally or commercially.
Document the roles and responsibilities of your team members to clarify goals. If possible, integrate these assignment terms of reference with your organizations performance
management system. When you institute regular reviews of your staffs performance, you can focus your team on project goals and also provide valuable feedback to them and
the consulting practice.
The Project Orientation Guide has been developed to communicate the basic project information to the project team. Update and redistribute it to team members as the
requirements change to maintain consistent performance throughout the project.
Quality Management
Quality Management tasks during the Project Execution and Control phase should be carefully coordinated with execution tasks. Product quality assurance techniques should
include walkthroughs, inspections, technical reviews, and work product reviews. Process quality assurance techniques you will use include auditing, healthchecks, measurement,
and analysis.
Follow the quality assurance process and quality control guidelines documented in the Quality Plan.
Enforce Quality Measures
Integrate quality measurement into every task in some way. Schedule quality reviews to provide visibility and focus management attention on your phases key work products.
Warning: Follow the Project Management Plan on all levels, and do not compromise, even if the project is on a tight schedule. Once you begin to cut corners on delivering quality,
you will ultimately absorb the consequences. Avoid making these types of compromises. It is important that the level of quality measures on the project be appropriate and
accounted for in the Project Management Plan.
Improve the Process
Every quality measure should be able to communicate a message back, whether the message is positive or negative. In any case, the feedback should be constructive and
informative. The recipients of the feedback should never feel like they are being policed by some governing body. Also, your feedback should never be just an identification of
problems. It should always include examples, approaches, and techniques for improving the process, as implemented by the project. A Quality Plan is only effective if you can
take the results and improve the process directly on your project. If you merely measure results, then you have missed the whole point of instituting quality measures.
Configuration Management
During Phase Execution and Control and throughout the project, use Configuration Management tasks to protect the integrity and content of your previous phase baselines and
current phase work products. Configuration Management is a project management process, because it implements policies you establish to safeguard your work products. On an
information technology project, software often represents a large portion of the value your project delivers. Software configuration management (SCM) is especially important to
project managers, because it provides visibility and organization to highly intellectual, intangible software work products.
Make SCM a Natural Part of Project Work
SCM controls are meant to protect much more than damage to work products. Software configuration control includes implementing the appropriate software change, but also
making sure to update any previous or existing work product affected by the change. For example, analysis and design specs/documents must be updated to reflect changes
implemented "downstream". SCM includes managing change and enforcing consistency.
Suggestion: Try to make the SCM system on your project a natural extension of your software development or implementation environment. By doing this, you can enforce SCM
standards while at the same time fostering teamwork, confidence, and security.
Allow Time to Prepare Intellectual Capital
Cleansing of sensitive, proprietary, or confidential information from project work products may require significant effort if the work products are to retain the value of cumulative
project experience. It is important to include an adequate amount of effort in the project workplan to support the effort of identifying what, if anything, should be edited for a larger
viewing audience. As the inventory of reusable components grows, the business will benefit from the reduced effort in the earlier phases of the project since previous knowledge
and work products will be available to offset the cleansing effort. Refer to the contractual requirements prior to scheduling Knowledge Management. Schedule a knowledge
review at the end of each major milestone or phase to facilitate work product preparation.
Attention: Scheduling and conducting a knowledge review helps the project manager facilitate gathering reusable work products and helps ensure that they are properly
cataloged. Knowledge reviews also allow the project team to become aware of other similar projects and the potential use of intellectual capital from those projects.
Managing Project Iterations/Phases
Most projects are divided into multiple units of work resulting in a key milestone. Project phases and project iterations are common examples of how we divide project tasks during
Project Execution and Control.
Iteration/Phase Start Up
At the beginning of each iteration or phase, the Project Management Plan (the key output from the Project Start Up phase) should be revisited and updated as appropriate. The
same process for obtaining approvals will apply during Iteration/Phase Start Up as applied during Project Start Up.
Key areas that are important to revisit/revise during Phase Start Up or iteration start up include (but are not limited to) the project scope, key iteration/phase work products, work
breakdown structure, and staffing.
Iteration/Phase Control
All the tasks in the Project Execution and Control phase are conducted when controlling an iteration/phase. There is no distinction between executing and controlling the project
and executing and controlling an iteration/phase.
Iteration/Phase Completion
At the end of an iteration/phase, the following key Project Execution and Control phase tasks should be conducted.
STM.006 Manage Project Team
QM.050 Perform Quality Assurance
WM.050 Gain Approvals
CMM.030 Manage Project Team Communication
Other Project Execution and Control tasks may be performed as necessary.
Scrum
If you are using a Scrum approach, use the Managing an OUM Project using Scrum technique. Use this link to access the phase-specific guidance for Scrum.
Back to Top
TASKS AND WORK PRODUCTS
This phase includes the following tasks:
ID Task Work Product Key Type
Manage Scope, Acceptance and Approvals
SM.030 Manage Scope Managed Scope Y Core
SM.040 Manage Acceptance Managed Acceptance Y Core
WM.050 Manage Approvals Managed Approvals Y Core
Manage Project Finances
FM.040 Manage Project Finances Managed Project Finances Y Core
Manage Project Workplan
WM.030 Manage Project Workplan Project Workplan Y Core
WM.040 Track Schedule Performance Schedule Performance Core
Manage Risk, Issues and Problems
RKM.040 Manage Risk Managed Risk Y Core
RKM.050 Monitor and Control Risk Assessed Risk Core
IPM.040 Manage Issue and Problems Managed Issue and Problems Y Core
Orient and Manage Team
QM.030 Conduct Project Team Quality Management Orientation Project Team Quality Management Orientation Core
STM.050 Conduct Team Orientation Oriented Team Y Core
STM.060 Manage Project Team Managed Project Team Y Core
Manage Communications and OCM Plans
CMM.030 Manage Project Team Communication Project Team Communication Y Core
OCHM.030 Execute Change and Communication Plan Executed Change and Communication Plan Y Core
Manage Project Quality
QM.040 Perform Quality Control Quality Control Y Core
QM.050 Perform Quality Assurance Managed Quality Assurance Y Core
Create and Execute Configuration and Release Management
CM.040 Create and Execute Software Configuration Management Plan Software Configuration Management Plan Y Core
CM.050 Create and Execute Software Release Management Plan Software Release Management Plan Y Core
CM.060 Create and Execute Environment and Patch Management Plan Environment and Patch Management Plan Y Core
CM.070 Create and Execute Configuration Control Plan Configuration Control Plan Y Core
Manage and Maintain Infrastructure
IFM.040 Manage and Maintain Infrastructure Maintained Infrastructure Y Core
Manage and Maintain Infrastructure
PCM.030 Administer Procurement of Goods and Contracted Services Managed Procurement of Goods and Services Y Core
Back to Top
ACTIVITY FLOW DIAGRAM
The Project Execution and Control phase is made up of ongoing tasks. In general, ongoing tasks are conducted as needed and not dependent on other tasks in the workplan.
Some tasks, such as reporting tasks, are performed based on a predetermined schedule. This schedule is normally determined and agreed on during the Project Start Up phase.
Tasks that are expected to occur at specific time (i.e., the first Friday of every month), should be added to the project plan.
Back to Top
CRITICAL SUCCESS FACTORS
These factors have been shown to be critical to the success of this phase:
Scope, objectives, and progress of the phase are agreed on and understood by all parties.
All policies, standards, and procedures are incorporated into the tasks comprising the work breakdown structure for the project.
All forms of project communications comprising meetings, reports, documents whether physical or electronic are clear, concise, accurate, and timely to all project team
members.
Commitment from project stakeholders to the projects objectives is maintained.
Continued management of organization and team expectations.
Ensure alignment of project direction and business objectives.
Issues, change requests, problems, and risks are recorded, tracked, reviewed and resolved on a timely basis with clear communication of these items to all parties, and
especially the project sponsors.
Change requests are recorded in a formal way, e.g., documented with analysis of the impact of each change and presented to both organization and implementing
organization sponsors as well as the project change control board.
Project workplans and finance plans accurately capture the work effort and reflect approved change requests.
Project estimate to complete is regularly and consistently updated based upon actual progress against planned progress.
Project management supports and enforces quality measures.
Project work products are protected from unauthorized change and baselines are fully compliant with project requirements.
Back to Top
QUALITY CRITERIA
At the end of this phase, the following criteria should be met or exceeded
Are regular status meetings conducted with project sponsors, and the project teams as well as executive management?
Are change requests recorded, assessed and when appropriate, reviewed with the Change Control Board?
Were project progress reporting requirements gathered? Are these practices followed consistently and on a timely basis?
Have these procedures been incorporated into the projects standards and procedures?
Have all reusable work products been sanitized, reviewed for "leading practices," and harvested for reuse?
Were Healthchecks conducted? Were the results acknowledged and closed out?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MSAA - MANAGE SCOPE, ACCEPTANCE AND
APPROVALS
This activity includes all of the ongoing Manage tasks for managing scope, acceptance and approvals.
Back to Top
OBJECTIVES
The objective of this activity is to manage scope, acceptance and approvals.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
SM.030 Manage Scope Managed Scope Change Request Form
Change Request Log
SM.040 Manage Acceptance Managed Acceptance Acceptance Criteria
Acceptance Certificate
WM.050 Manage Approvals Managed Approvals Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Put into practice the processes documented in the Scope Change Management Processes and manage any possible scope changes (Change Requests) as
defined.
Gain acceptance from the client on the completed work products.
Manage the approval of project work products based on the procedures defined in the Work Product Approval Process component of the Work Management Plan.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MPF - MANAGE PROJECT FINANCES
This activity includes the ongoing Manage task to manage the project financials during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is execute and control the project to deliver within budget and on-time.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
FM.040 Manage Project Finances Managed Project Finances Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
The task within this activity is ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Put into practice the processes documented in the Financial Management Plan and the Time and Expense Tracking and manage the financial aspects of the
project.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MPW - MANAGE PROJECT WORKPLAN
This activity includes all of the ongoing Manage tasks to manage the Project Workplan and track the scheduled performance during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is put into practice the strategy, processes and procedures documented in the Work Management Plan to engage resources to execute the
Project Workplan as well as periodically measuring actual project accomplishments against what was planned.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
WM.030 Manage Project Workplan Project Workplan Assignment Request
Deliverable Tracking Spreadsheet
Unplanned Activity Log
Iteration End Report
WM.040 Track Schedule Performance Schedule Performance Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Put into practice the strategy, processes and procedures documented in the Work Management Plan to engage resources to execute the Work Management Plan
and regularly review and update the Project Workplan with the actuals.
Track scheduled performance in order to measure actual project accomplishments against what was planned.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MRIP - MANAGE RISKS, ISSUES AND PROBLEMS
This activity includes all of the ongoing Manage tasks for managing risks, issues and problems.
Back to Top
OBJECTIVES
The objective of this activity is to manage risks, issues and problems.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
RKM.040 Manage Risk Managed Risk Refer to the Task Overview for guidance.
RKM.050 Monitor and Control Risk Assessed Risk Monitor and Control Risk
IPM.040 Manage Issues and Problems Managed Issues and Problems Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Execute the process detailed in the Risk Management Plan for the potential risks identified in the Identified Risks Watch List.
Executing the procedures detailed in the Risk Management Process for unplanned or NEW risks that were not already identified in the Identified Risks Watch List.
Put into practice the processes documented in the Issue Management Strategy and Problem Management Strategy and manage any issues/problems as defined.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.OMT - ORIENT AND MANAGE TEAM
This activity includes all of the ongoing Manage tasks to conduct the team orientation(s) and manage the project team during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is to conduct the team orientation(s) and manage the project team during the execution of the project.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
QM.030 Conduct Project Team Quality Management
Orientation
Project Team Quality Management
Orientation
Project Team Quality Management Orientation
Presentation
STM.050 Conduct Team Orientation Oriented Team Project Kickoff Presentation
STM.060 Manage Project Team Managed Project Team Individual Status Report
Assignment Request
Assignment Terms of Reference
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Conduct Project Team Quality Management Orientation. This orientation can be conducted as part of the Project Kickoff meeting.
Plan and conduct a Project Kickoff meeting to orient the team to the project. If necessary, similar orientation meetings can be given for new team members that join
the project after kickoff.
Put into practice the procedures documented in the Staff Management Plan and manage the staff.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MCOP - MANAGE COMMUNICATIONS AND OCM
PLANS
This activity includes all of the ongoing Manage tasks to communicate with the project team and the client organization that are performed during the execution of the
project.
Back to Top
OBJECTIVES
The objective of this activity is to effectively communicate with the project team and the client organization.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
CMM.030 Manage Project Team Communication Project Team Communication Meeting Minutes
Weekly Project Status Report with Instructions
Weekly Project Status Report
OCHM.030 Execute Change and Communication Plan Executed Change and Communication Plan Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Put into practice the reporting requirements, scheduled meetings and procedures documented in the Project Team Communication Plan and manage
communication.
Execute the Change and Communication Plan developed as part of the Client's Organizational Change Management Strategy.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MPQ - MANAGE PROJECT QUALITY
This activity includes all of the ongoing Manage tasks to manage quality control and perform quality assurance during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is manage quality control and perform quality assurance.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
QM.040 Manage Quality Control Quality Control Review Comments List
Review Leader Form
QM.050 Perform Quality Assurance Managed Quality Assurance Audit Action Report
Audit Report
Quality Report
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Execute the Quality Control and Reporting Process.
Apply the planned, systematic quality activities and any ongoing processes documented in the Quality Management Plan to ensure that the project employs all
delivery processes needed to meet requirements.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.CECRM - CREATE AND EXECUTE CONFIGURATION
AND RELEASE MANAGEMENT
This activity includes all of the ongoing Configuration Management tasks that are performed during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is to establish the Software Configuration Management Plan, the Software Release Management Plan, the Environment and Patch
Management Plan and the Configuration Management Control Plan as well as monitor the key elements of configuration management identified in the Configuration
Management Control Plan and making any adjustments, as necessary.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
CM.040 Create and Execute Software Configuration Management Plan Software Configuration Management Plan Software Configuration Management Plan
CM.050 Create and Execute Software Release Management Plan Software Release Management Plan Software Release Management Plan
Release Note
CM.060 Create and Execute Environment and Patch Management Plan Environment and Patch Management Plan Environment and Patch Management Plan
CM.070 Create and Execute Configuration Control Plan Configuration Management Control Plan Configuration Management Control Plan
Back to Top
ITERATIONS
The tasks within this activity are ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Create and execute the Software Configuration Management (SCM) Plan.
Create and execute the Software Release Management Plan.
Create and execute the Environment and Patch Management Plan.
Create and execute the Configuration Management Control Plan.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.MMI - MANAGE AND MAINTAIN INFRASTRUCTURE
This activity includes the ongoing Manage task to manage and maintain the infrastructure during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is to manage and maintain the project infrastructure.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
IFM.040 Manage and Maintain Infrastructure Maintained Infrastructure Equipment Fault Record
Back to Top
ITERATIONS
The task within this activity is ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Monitor Infrastructure Management activities using the processes, procedures, controls and metrics defined in the Infrastructure Management Plan.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
#TOP #TOP
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PEC.ACT.APGCS - ADMINISTER PROCUREMENT OF GOODS
AND CONTRACTED SERVICES
This activity includes the ongoing Manage task to administer the procurement of goods and contracted services during the execution of the project.
Back to Top
OBJECTIVES
The objective of this activity is to administer the procurement of goods and contracted services.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
PCM.030 Administer Procurement of Goods and Contracted Services Managed Procurement of Goods and Services Incoming Item Record
Rejection Note
Back to Top
ITERATIONS
The task within this activity is ongoing for the duration of the project.
Back to Top
APPROACH
The approach to this activity is to:
Manage the procurement of goods and services based on the previously defined Procurement Strategy and Process.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.CPMP Complete Project Management Plan
PS.ACT.EPI Establish Project Infrastructure
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[PC] PROJECT CLOSURE
The purpose of the project closure phase is to validate that the project work products or task outputs are complete and are aligned with the accepting organizations
expectations, gain final acceptance and close the project. The team must also review the project work products for examples of leading practices. These work products
should be secured for reuse, collection and retention of empirical data.
A project or phase of a project will be considered closed when all Project Management and work products have been completed, approved by necessary approving
bodies and archived.
Two types of closure activities are described in Manage:
Administrative Closure:
Administrative closure is classified as the mechanical and analytical steps associated with the closure activities associated with either the conclusion of a phase or project.
These steps are clerical, organizational, and diagnostic in nature and are meant to serve as a vehicle to bring to a successful conclusion (with the appropriate level of
rigor) all aspects of project operations.
Typically tasks associated with administrative closure procedures are:
Completing closure checklists
Completing proper signoff documentation
Archiving all project documentation
Reviewing final project work products with project stakeholders
Completing lessons learned documentation and review sessions
Completing project acceptance reports
Closing or transitioning all outstanding issues
Closing or transitioning all outstanding risks
The Project and Phase Close-Out procedures are comprised in the following steps and are administrative in nature:
Closeout Checklists - There are checklists, to be completed throughout the lifecycle of the project, which are at the Project level, the Phase level, and at the
Contractual level.
Conduct Lessons Learned - The Project Manager conducts the Lessons Learned process with the project team and documents all findings.
Project Acceptance Report - At the conclusion of a project there is a requirement to produce a project acceptance report which assembles all the key information
related to the project operations.
Operational Sustainment Report - At the conclusion of the project and when the project team transfers operational support duties to the sustaining operational
organization there may be a requirement to develop an operational sustainment report. This report is intended to provide key information to the sustaining
organization regarding unique support and operation requirements of the solution and key developments during the post-production support and stabilization
period.
Archive All Project Documents - It is prudent for all documentation to be archived
Contractual Closure:
Contractual closure is classified as the obligatory steps associated with the completion of contractual requirements. Contractual closures can be with external vendors or
internal through service level agreements. Typical tasks associated with contractual closure procedures are:
Review all contractual obligations.
Secure sign-off on all contractual obligations.
Secure payment for final invoices.
Obtain written acceptance.
Learn new ways to improve satisfaction and thus the number of references.
The following represent the contractual closeout procedural requirements for external vendors:
Review all contractual deliverables to enable acceptance and address all open items.
Review prior, current, and pending invoicing activities.
Review all approved change requests for completeness.
The following represents the service level agreement closeout procedural requirements:
Secure hardcopy or electronic version of all sign-off forms
Review all service level agreement deliverables to enable acceptance and address all open items.
Review all approved change requests for completeness.
Review all service level incidences.
Back to Top
OBJECTIVES
The following is a list of the objectives of this phase:
Make sure that the business requirements and expectations have been aligned to the organization's expectations.
Record all project data and metrics as well as lessons learned from the project.
Obtain formal acceptance of the project.
Pay all invoices.
Capture and submit project intellectual capital.
Close out the project by following an exit plan.
Release staff and physical resources.
Gain final acceptance of all project work products.
Close out the contractual agreement, if any, with the accepting organization.
Hand over project work products and environments to the production support team (as appropriate).
Document and archive project results.
Back to Top
PROCESSES
The Manage context diagram illustrates the processes within the Project Closure phase.
Back to Top
TIPS AND TECHNIQUES
This section discusses techniques that may be helpful in conducting Project Closure including the managing the administrative and contractual closing of the project with
the accepting organization and the delivery organization. Techniques you find most useful are communicating, negotiating, and conflict resolution. The general approach
recommended for Project Closure is to make the accepting organization responsible for conducting agreed upon acceptance tasks, such as testing. However, specific
terms and conditions may be detailed in the contractual agreement and should be reflected in project management plans.
Manage Acceptance Expectations Carefully
When conducting Project Closure, remember to continue to manage changes, issues, and problems throughout acceptance. Last minute issues and problems can be
quite common, as client stakeholders realize that they have only a short time remaining to influence project results. The project sponsor and project manager, from the
accepting organization, should take a leadership role at this point in the project to control the introduction of new issues which may be more accurately classified as future
enhancements. Use of the MoSCoW list and conducting incremental reviews, throughout the engagement can assist in avoiding such issues
Feed Back Results to the Delivery Organization
It is easy to focus on contractual and resource issues during the final days of a project. However, do not forget that your project has advanced the capabilities of the
delivery organization and has hopefully produced a product that the delivery team and the accepting organization are proud of. While you have the time, staff, and
accepting organization contacts available, make sure to feed project results back to the delivery organization. Use the Project End Report to capture information about
the project for future use and to benefit future projects. The Satisfaction Report will provide objective information about project results to the delivery organization
management team.
Staff Management
Coordinate closely with your delivery organization business manager about resource needs after the project closes (or the engagement is considered complete). There
may be uncompleted negotiations regarding a support or ongoing maintenance requirements which could retain some of the project staff. Ideally, post-project
commitments have been established before the project begins. Depending on the length of the project requirements may have changed regarding what happens after the
project. Once post-project commitments to the accepting organization have been refined, staff can be reallocated. In practice, as the project is in the completion phase,
then reallocation can be started.
Physical resources can easily become lost or intermixed in a project infrastructure shared with the accepting organization. If you have maintained accurate equipment
records, you should be able to sort out which equipment, licenses, and materials are to be retained by the delivery organization and which will be retained by the
accepting organization. The project agreement or contract contains this information and should be reviewed as part of this closing phase.
Quality Management
At this point in the project, previous phase acceptances should have already established a clear pattern of quality compliance. Use the final Quality Report as a tool to
support your final approval, or to help resolve any contractual disputes or issues regarding the quality of your project work products
Configuration Management
The transfer of the Configuration Management environment to the accepting organization should be coordinated with transfers of other project environments, specifically
those for development, maintenance, and testing. The amount of transfer is project-specific, and should be worked out well in advance, ideally as part of the contractual
agreement.
Archive Project Work Products
Configuration Management is also responsible for transferring archive copies of project work products to your consulting practice. Follow your practice policies and
procedures about archiving project work products. Consider these questions before contributing your work:
Do you have the legal right to remove work products? Check the contractual agreement. Also, it is good practice to inform the accepting organization of your
intentions and ask for permission, even if you have legal authority.
Does the accepting organization have any legal or other reservations about using the accepting organization name in the body of the materials? If so, then you
must replace that name with one that is generic so work products cannot be traced to the accepting organization.
Does the work product require any more information in order to be a valuable project artifact? If so, then add a preface to the work product with the proper
explanation or substitute the work product prior to adding to any knowledge management system or project archive.
Attention: Take legal restrictions seriously. The accepting organization may have confidential information that if disclosed, even as a sample, to their competitors would
be detrimental to their position in the marketplace. The delivery organization has an obligation to protect the information of accepting organization. You may be placing
the accepting organization in legal and financial risk if you were to disclose such information.
Scrum
If you are using a Scrum approach, use the Managing an OUM Project using Scrum technique. Use this link to access the phase-specific guidance for Scrum.
Back to Top
TASKS AND WORK PRODUCTS
This phase includes the following tasks:
ID Task Work Product Key Type
Gain Acceptance
SM.030 Gain Acceptance Final Acceptance Certificate Y Core
Close Processes and Contract
SM.060 Close Scope Management Closed Scope Management Core
SM.070 Identify Future System Enhancements Future System Enhancements Core
FM.050 Close Project Financials Closed Project Financials Y Core
WM.060 Close Work Management Closed Work Management Y Core
RKM.060 Conduct Post-Production Risk Assessment Post-Production Risk Assessment Y Core
IPM.050 Produce Final Issue and Problem Report and Close Log(s) Closed Issue and Problem Log Core
STM.070 Release Staff Released Staff Core
CMM.060 Submit Final Reports Final Reports Core
QM.060 Conduct Post-Production Quality Review Post-Production Quality Review Y Core
CM.080 Close Configuration Management Closed Configuration Management Core
IFM.050 Close Infrastructure Closed Infrastructure Core
PCM.040 Close Contract Closed Contract Y Core
OCHM.040 Establish Follow-up Process Follow-up Process Core
Document Lessons Learned and Archive Project
CMM.040 Document Lessons Learned Lessons Learned Y Core
CMM.050 Turn Over Project Documentation Project Archives Y Core
Back to Top
ACTIVITY FLOW DIAGRAM
Back to Top
CRITICAL SUCCESS FACTORS
These factors have been shown to be critical to the success of this phase:
The accepting organization perceives the value of the project.
The expectations and business requirements of the accepting organization have been met.
Satisfaction concerns are identified and addressed prior to requesting acceptance of work products.
All financial obligations are paid by the accepting organization.
The accepting organization will provide references.
The projects financial performance criteria has been accurately measured.
Outstanding issues and problems which affect phase work products are resolved prior to their acceptance.
Change control, configuration control, and quality records are complete and accurate, and demonstrate compliance with project standards.
Early attention was given to acceptance planning and definition of acceptance criteria.
Good relationship between delivery and accepting organization achieve through collaboration and managed expectations.
Incremental reviews have been conducted throughout the project (with adequate attendance by accepting organization) and time has been allowed for rework
during incremental acceptance. This results in less time begin needed for rework in the final acceptance.
Back to Top
QUALITY CRITERIA
At the end of this phase, the following criteria should be met or exceeded
Have the accepting organizations business requirements been satisfied?
Have the accepting organizations expectations been met?
Has the accepting organization approved all final work products?
Has the final project work product been packaged and signed off by the accepting organization?
Have all outstanding financial obligations been paid?
Have all work products been harvested for reuse?
Does the project manager understand document retention requirements?
Have all open issues been resolved?
Have all problems been resolved?
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PC.ACT.GA - GAIN ACCEPTANCE
This activity includes gaining formal acceptance for the project from the client.
Back to Top
OBJECTIVES
The objective of this activity is to gain formal project acceptance.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
SM.050 Gain Acceptance Final Acceptance Certificate Acceptance Certificate
Project Acceptance Report
Back to Top
ITERATIONS
This activity is iterated once.
Back to Top
APPROACH
The approach to this activity is to:
Review the contract to make certain that all contractual obligations are met.
Ensure that all sign-offs have been received.
Back to Top
PREREQUISITES
You will need the following for this activity:
Contract
PS.ACT.CPMP Complete Project Management Plan
Project Execution and Control Activities
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PC.ACT.CPC - CLOSE PROCESSES AND CONTRACT
This activity closes out the project processes for each of the project management processes. In addition, the contract is reviewed to make sure that all obligations have
been met.
Back to Top
OBJECTIVES
The objective of this activity is to update all final reports and verify that the contract obligations have been met.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
SM.060 Close Scope Management Closed Scope Management Scope Management Lessons Learned
SM.070 Identify Future System Enhancements Future System Enhancements Future System Enhancements
FM.050 Close Project Financials Closed Project Financials Financial Management Lessons Learned
WM.060 Close Work Management Closed Work Management Work Management Lessons Learned
RKM.060 Conduct Post-Production Risk Assessment Post-Production Risk Assessment Post-Production Risk Assessment
Risk Assessment Lessons Learned
IPM.050 Produce Final Issue and Problem Report and Close Log(s) Closed Issue and Problem Log Issue and Problem Management Lessons Learned
STM.070 Release Staff Released Staff Refer to the Task Overview for guidance.
CMM.060 Submit Final Reports Final Reports Project Closure
End Report
Engagement Summary
QM.060 Conduct Post-Production Quality Review Post-Production Quality Review Client Satisfaction Report
Project Healthcheck Checklist
Metrics Report
CM.080 Close Configuration Management Closed Configuration Management Configuration Management Lessons Learned
IFM.050 Close Infrastructure Closed Infrastructure Refer to the Task Overview for guidance.
PCM.040 Close Contract Closed Contract Supplier Assessment Record
OCHM.040 Establish Follow-Up Process Follow-Up Process Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
This activity is iterated once.
Back to Top
APPROACH
The approach to this activity is to:
Close processes and reports for each of the Project Management processes.
Close contract.
Establish follow-up procedures.
Back to Top
PREREQUISITES
You will need the following for this activity:
Contract
PS.ACT.CPMP Complete Project Management Plan
Project Execution and Control Activities
PC.ACT.GA Gain Acceptance
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
PC.ACT.DLLAP - DOCUMENT LESSONS LEARNED AND
ARCHIVE PROJECT
This activity compiles the lessons learned through project execution and control and it archives the project.
Back to Top
OBJECTIVES
The objective of this activity is to document areas of improvement for future engagements and areas that were performed well.
Back to Top
TASKS
The tasks included in this activity are:
Task Overview Work Product Template
CMM.040 Document Lessons Learned Lessons Learned Lessons Learned
CMM.050 Turn Over Project Documentation Project Archives Refer to the Task Overview for guidance.
Back to Top
ITERATIONS
This activity is iterated once.
Back to Top
APPROACH
The approach to this activity is to:
Document Lessons Learned
Turn Over Project Documentation
Submit Final Reports
Back to Top
PREREQUISITES
You will need the following for this activity:
PC.ACT.GA Gain Acceptance
Project Execution and Control Activities
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[BT] BID TRANSITION
The Bid Transition process, although represented in Project Start Up, is in reality more of a project initiation task. The first major activity that a project manager is
expected to perform is to participate in the handoff from the "sales cycle" to the "delivery cycle".
It is critical to the success of the project that the project manager and any other groups/subject matter experts that will take part in the project have a full understanding of
important facets of the project such as the contract conditions, assumptions, project site, scope, staffing, financials, customer needs, work products, time schedule, cost,
performance criteria (quality), and business case.
It is important to recognize the difference between contract management and project management. For example, the contract determines the scope of the project, the
financial terms, project timeline, and the specific work products that are expected. A project manager must meet these contractual responsibilities. Project management
focuses on managing the scope, time schedule, responsibilities, and resources of the project. A good project manager must keep track of and control both the contractual
responsibilities and project responsibilities.
The project manager must accept the handover from sales. Acceptance means that the project manager is accountable for the project, not simply fully understanding the
context as a passive spectator, but accepts responsibility for the project with all the constraints handed over by the sales cycle. Because the sales cycle is not
responsible for delivery, the project manager should recalculate the cost and time schedule and if a deviation occurs re-negotiate the project conditions.
This must be achieved not only through review of the bid and proposal material, but also by having the bid team transition their understanding of the bid to all those
individuals involved in the start up of the project so that these individuals gain an understanding of the bids assumptions from all perspectives.
The bid material will contain the projects baseline information. However, this information must be validated both internally and with the client.
The bid material including project scope, project approach, key work products, and the acceptance criteria must be reviewed to determine any ambiguities, risks, issues,
and changes that must be addressed with the client during the validation process.
Obligations and the projects financials must be reviewed and validated with the owning cost center.
PROCESS FLOW
The Bid Transition process does not dictate a specific flow or order that the tasks should be performed. In general, the tasks should be performed sequentially, but no
constraints, other than the project manager's time, keep Bid Transition tasks from being performed in parallel.
Back to Top
APPROACH
The Bid Transition process is the first activity in the Project Start Up phase of Manage. It is critical to the project's success that the tasks outlined in the Bid Transition
process be performed. A project manager must understand the contract and must review that understanding with the customer.
In general, the Bid Transition process is the opportunity for the project manager to fully understand the business case and the contracted approach to meeting the
business objectives.
The Bid Transition process offers the project manager an opportunity to:
Meet with the Sales Team to ensure that the contract is understood.
Meet with the client to confirm the project scope, objectives, and project timeline. The business case and project approach should also be discussed and agreed.
Document any changes to the contract or bid material and to re-baseline the project with these changes.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS BT.010 Review and Analyze Bid Material Reviewed and Analyzed Bid Management Core
PS BT.020 Review and Confirm Business Case Confirmed Business Case Core
PS BT.030 Identify Project Stakeholders Identified Project Stakeholders Core
PS BT.040 Review and Accept Project Budget Accepted Project Budget Core
PS BT.050 Review Contract with Client Reviewed Contract Y Core
PS BT.060 Review Project Approach with Client Reviewed Project Approach Y Core
PS BT.070 Create Project Management Framework Project Management Framework Y Core
Back to Top
OBJECTIVES
The objectives of the Bid Transition process are:
Handoff the project from the Bid Team "sales cycle" to the Project Manager "delivery cycle".
Document and communicate the contractual responsibilities.
Document and communicate the project responsibilities.
Identify and document the Project Stakeholders.
Review and validate obligations and project financials.
Reach agreement between the project manager and the owning cost center as to the project scope, objectives, approach, budget and expected financials.
Reach agreement between the project manager and the client as to designated obligations and the project scope, objectives and approach.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Client (User)
CPS Client
Project
Sponsor
CPM Client
Project
Manager
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.010 - REVIEW AND ANALYZE BID MATERIAL
The Review and Analyze Bid Material task occurs after the project manager is assigned to the project. The project manager gathers and reviews all the available bid
material. This includes informal documentation from the sales team who participated in the demo such as their discovery documents, any non-standard requirements that
were noted and/or demonstrated to the customer and possibly correspondence between the implementing organization and the prospect. Some projects may not result
from a sales process. In this case, materials similar to a bid that would provide project background, deliverables and budget information should be used.
If the project manager determines that changes are needed to the bid Material or the contract, then these changes must be communicated to, reviewed with, and
approved by the appropriate areas.
Gather and review all bid material from contracts, operations, bid manager(s), and the Risk Management review.
Analyze and document key organizational risks.
Review contract for critical areas.
Confirm commitment to deliver.
ACTIVITY
PS.ACT.RBC Review Bid and Contract
Back to Top
WORK PRODUCT
Reviewed and Analyzed Bid Material - The Reviewed and Analyzed Bid Material may include the following components:
Reviewed Bid Material
Confirmed Presence of Key Organizational Risks
Reviewed Contract
Reviewed Contract work product Schedule
Commitment to Deliver Engagement
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Gather and review all bid material. Reviewed Bid
Material
The Reviewed Bid Material is a collection of all the material gathered,
organized and cataloged for reference as needed during the project.
2 Confirm presence of key organizational risks. Confirmed
Presence of Key
Organizational
Risks
The Confirmed Presence of Key Organizational Risks consists of a
stakeholder organizational chart showing the key stakeholders.
Include placeholders for TBD, unidentified or missing stakeholders.
Add identified risks to the overall project risk analysis.
3 Review the contract to determine critical areas. Reviewed
Contract
The Review Contract component document a summary of the critical
areas of the contract.
Add identified risks to the overall project risk analysis.
4
Review Contract's deliverable schedule.
Reviewed
Contract
Deliverable
Schedule

5 Confirm commitment to deliver. The project manager should verify they
can commit to the delivery of the project based on all updated
information. This includes scope, resources, timelines, project profit, etc.
Commitment to
Deliver
Engagement
The Commitment to Deliver Engagement is an email and/or other
communication that confirms the commitment to proceed with the
engagement.
Back to Top
APPROACH
Gather and Review Bid Material
If available, gather and review the following materials:
contract and associated documentation
bid documents
project organization
proposal or statement of work
project estimate
initial risk analysis
project staff plan
sub-contractor scope and contract terms, if applicable
approval emails
high-level workplan
business case (if completed by implementing organization, third-party or client)
client's request for information (RFI) and request for proposal (RFP) and request for quote (RFQ)
responses to RFI, RFP and RFQ
Confirm that you have the answers to the following 5 key questions regarding organizational risks:
Has the client experienced a merger or acquisition in the last three years?
Has the client faced previous failures in implementing new technologies?
Is this a multiple site implementation with all organizations (or subsidiaries) required to adapt to the implementing organization's leading practice processes which
will drive significant organizational change?
Will this project impact whether the organization will conduct business in a centralized or decentralized environment?
Are internal communications for employees mostly informal (i.e. ad hoc) and not a on a regular recurring basis?
Confirm Presence of Key Organizational Risks
Perform analysis to identify and confirm the availability and appointment of client sponsors, oversight or program management, infrastructure support, and other client
stakeholders.
Review Contract
Review the contract to determine critical areas.
Review Contract's Deliverable Schedule
Review the contract's deliverable schedule in the contract to determine milestones that need to be reflected in the projects workplan and possibly in the project
accounting structure.
Confirm Commitment to Deliver
Confirm commitment to delivery. The project manager should verify they can commit to the delivery of the project based on all updated information. This includes scope,
resources, timelines, project profit, etc.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Contract and Associated Documentation These are the bid materials you should get from the bid manager and review
Bid Documents
Project Organization
Proposal or Statement of Work (SoW)
Project Estimate
Initial Risk Analysis
Project Staff Plan
Sub-Contractor Scope and Contract Terms, if applicable
Approval Emails
High-Level Workplan
Business Case (if completed by implementing organization, third-party or client)
Client's Request for Information (RFI) and Request for Proposal (RFP) and Request
for Quote (RFQ)
Responses to RFI, RFP and RFQ
, if available.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BT010_REVIEWED_AND_ANALYZED_BID_MATERIAL.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.020 - REVIEW AND CONFIRM BUSINESS CASE
This Review and Confirm Business Case task makes certain that the project manager has a clear understanding of the business case for the project. A project manager
who understands the purpose of the project and clearly understands what the project is trying to achieve, will be much better equipped to address both the customer's
and the implementing organization's expectation for a successful project. This is especially important during the execution of the project when scope changes are
requested. The direction of the project should always tie back to the business case.
To help businesses achieve the transformations envisioned, project managers must take steps to verify that the project is closely aligned to an underlying business
strategy or business case from the outset. Specific business performance metrics should to be adopted, understood and confirmed throughout the projects life span to
validate project success. Defining and reviewing performance metrics will help keep the client focused on the actual business value of the project. Conversely, if there is
not a clear, compelling business case for the project and/or there is not a clear, direct connection between the project and a key business strategy, the project manager
should treat this gap as a major risk to the client and the project
ACTIVITY
PS.ACT.RBC Review Bid and Contract
Back to Top
WORK PRODUCT
Confirmed Business Case
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Review or identify the Business Objectives, Critical
Success Factors and associated Specific
Performance Metrics.
Business Case The Business Case describes what business objectives are being satisfied by the
project. It includes Business Objectives, Critical Success Factors and
Performance Metrics.
2 Identify specific Business Performance Metrics. Business Performance
Metrics
The Business Performance Metrics document the metrics.
Specific Performance Metrics may not have been gathered during the sales
cycle.
3 Identify gaps as project risks. Business Case Gaps The Business Case Gaps documents gaps as project risks.
4 Consider hosting an Executive Workshop to fill gaps. Business Case Gaps
Executive Workshop (if
appropriate)

Back to Top
APPROACH
The project manager has to know the critical success factors of the project. Projects can finish on time, under budget, and within scope, but be deemed a failure. If a
team finishes a project without regard to whether the work addresses the needs of the stakeholders, the project is unsuccessful.
In some cases, the original request for proposal and the associated response will identify the projects business objectives. If the project manager has not been involved in
the sales cycle, the project manager should contact the appropriate personnel within the implementing organization (for example, account executive, product consultants,
client executive, or anyone else who was involved in the sales cycle) to find out what was discussed during the demonstrations and if any hot issues surfaced at that
time.
The original request for proposal (RFP) may also give a good indication of what the organization considered to be important objectives prior to reviewing any vendors
products. If the RFP does not define the objectives, ask to see the clients internal documents that describe the business objectives the project is expected to achieve.
Ideally, the business case will focus on concrete business objectives and will identify an associated metric for each objective. It should be possible to map the business
objectives back to the business requirement definition. The objectives should be prioritized by the positive impact each will have on the organization. This is a good
opportunity to gain consensus on which objectives will be addressed as part of the current project and which will be deferred to a subsequent phase.
Some examples of business objectives include:
Decrease cycle counting cost by XX% with better inventory tools
Close the books Y days earlier with integrated applications
Generate invoices quicker and more accurately with improved pricing techniques
If none of the business objectives are written or documented, consider an Executive Strategy workshop with the major stakeholders, executives, and key users. The
workshop should drive out key business objectives that led to the software purchase. Oracle offers Executive Workshops.
Back to Top
SUPPLEMENTAL GUIDANCE
SOA Application Integration Architecture (AIA) Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Application Integration Architecture (AIA) implementation. Use the following to
access the task-specific supplemental guidance. To access all SOA AIA supplemental information, use the OUM SOA AIA Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Bid Material (Bid Preparation and Bid Review Process)
Contract (Contract Preparation Process)
Review these materials to confirm the Business Case.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BT020_CONFIRMED_BUSINESS_CASE.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.030 - IDENTIFY PROJECT STAKEHOLDERS
A stakeholder is defined as a person, group, or business unit that has a share or an interest in a particular activity or set of activities.
In this task, identify project stakeholders. Project stakeholders should be identified as early as possible. The success of the project increases when an active stakeholder
is identified and involved with the project.
Identify a stakeholder who has a vested interested in completing the project successfully. Optimally, the stakeholder should have the authority and contacts to influence
others to commit resources to the project.
ACTIVITY
PS.ACT.RBC Review Bid and Contract
Back to Top
WORK PRODUCT
Identified Project Stakeholders
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify implementing organization stakeholders. Internal Stakeholders This component lists all the stakeholders from the implementing
organization, that is, the project manager's organization.
2 Identify client (end user) stakeholders. Client (end user)
Stakeholders
This component lists all the stakeholders from the client
organization.
3 Identify prime contractor stakeholder (if a third party organization is
involved as the primary implementing organization).
Prime Contractor
Stakeholders (if
appropriate)
This component lists all the stakeholders from the third-party
organization.
4 Identify sub-contractor stakeholders (if a third party organization is
involved but not acting as the primary).
Sub-contractor
Stakeholders (if
appropriate)
This component lists all the stakeholders from the third-party
organization.
Back to Top
APPROACH
For each organization, identify the stakeholders along with each stakeholders interest and influence in the project. At a minimum these should include the executive
sponsors, other sponsors, the functional organizations and/or individuals who will use the environment resulting from the project, the project manager(s), and
organizations providing resources to the project effort. Stakeholder interests and influence may overlap or there may be identifiable differences between the interests of
some stakeholders.
All stakeholders may be identified in a single form document although occasionally it may be appropriate to use a separate form to identify stakeholders for separate
organizations.
Back to Top
SUPPLEMENTAL GUIDANCE
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Sales Team Notes (Bid Development Process)
Bid Team Notes (Bid Review Process)
Review these items to identify potential project stakeholders.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Stakeholder Capturing This technique provides guidance on what information should be captured about each stakeholder.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BT030_IDENTIFIED_PROJECT_STAKEHOLDERS.XLS MS EXCEL
All stakeholders may be identified in a single form although occasionally it may be appropriate to use a
separate form to identify stakeholders for separate organizations.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.040 - REVIEW AND ACCEPT PROJECT BUDGET
The expectation is that the bid financials will be adopted as the project budget. In the Review and Accept Project Budget task, the project manager reviews the bid
financials prior to establishing the initial Project Baseline Budget. If after the review, the project manager can make a compelling, fact-based argument to the responsible
Portfolio Management team that the bid financials are not achievable, a revised baseline project budget may be set and agreed to. This revised budget baseline (revenue
and margin) becomes the financial targets to which the project will be held.
The final, agreed upon project budget (revenue and margin) must then be documented and used as a baseline to monitor the projects financial performance.
ACTIVITY
PS.ACT.RBC Review Bid and Contract
Back to Top
WORK PRODUCT
Accepted Project Budget
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Review initial bid financials and create
Baseline Project Budget.
Baseline Project Budget
At a minimum, the Baseline Project Budget includes:
the final bid material
the estimate
the final Contract
Suggestion: Create a .zip file for the Baseline Project Budget including all of its
components. Made the Baseline Project Budget available to appropriate team members
through a project workspace or another collaborative environment.
2 Verify the budget with the final
contract and assumptions. Create a
revised estimate as necessary.
Revised Project Budget
3 Verify or create the staff plan. Revised Project Staff Plan
4 Apply the appropriate expenses,
Hosting, etc. to accurately estimate
the total cost.
Revised Project Cost
Estimates

5 Verify the revised project financials
against the bid financials.
Verified Project Financials
6 Discuss the results of the review with
the Portfolio Management team.
Meeting Notes Documenting
the Results of the Discussion
and Final Agreement

7 Accept project budget. Accepted Project Budget. Once the project budget is accepted, the appropriate time and expense tracking system can
be set up.
Back to Top
APPROACH
Use your organization's estimating tool or model to verify the project estimate or create the revised project estimate.
Document the required Staff Plan by level over time along with other factors such as but not limited to hosting and sub-contractors etc. and to document the final revised
project budget for cost, revenue and margin.
Back to Top
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Reviewed and Analyzed Bid Material (BT.010)
Confirmed Business Case (BT.020)
This material contains the information you need to review and accept the project budget.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.050 - REVIEW CONTRACT WITH CLIENT
It is essential to the overall success of the project for the project manager to reach a clear understanding and agreement with the client stakeholders as to the scope,
objectives, approach, assumptions and contractual terms governing the project. To facilitate this understanding and to establish a positive foundational relationship for
the project, the project manager conducts a contract review with the client project sponsor, project management and any third-party project managers.
During this review, the following items should be discussed:
Review the contract with the client.
Determine adequacy of all contractual roles in the engagement.
Understand explicit deliverables. Clarify implicit deliverables such as performance tuning, etc.
Review and validate the project acceptance criteria. Make sure both parties agree on the acceptance criteria and that they are well documented. This includes
agreement/PM sign-off.
Document all gaps and agreements.
ACTIVITY
PS.ACT.RPAC Review Project Assets with Client
Back to Top
WORK PRODUCT
Reviewed Contract
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Review the contract with the client. Understanding of Explicit and
Implicit Deliverables
None
2 Determine adequacy of all contractual
roles in the engagement.
Contractual Roles The Contractual Roles lists all the roles for the engagement and verifies the project
roles meet the given expectations in the contract.
3 Review and validate the project
acceptance criteria.
Validated Project Acceptance
Criteria

4 Identify all gaps and agreements. Gaps, Agreements, and Action
Items

Back to Top
APPROACH
Review the Contract with the Client
Understand explicit deliverables. Clarify implicit deliverables such as performance tuning, etc.
Determine Adequacy of All Contractual Roles
Determine adequacy of all contractual roles in the engagement, that is, is the project staffed appropriately given the expectations in the contract.
Review and Validate the Project Acceptance Criteria
Make sure both parties agree on the acceptance criteria and that they are well documented. This includes agreement/PM sign-off.
Identify All Gaps and Agreements
Following the client meeting, document to the client, in writing, the areas of agreement, gaps, and action items. The action items should include the name of the person
responsible for the action and the date the action should be completed. One action item may be to initiate the first Scope Change for the project that may or may not
have a financial impact on client funding. It does however set an example for the use of the Scope Management process.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
25
Project Manager 75
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Contract (Contract Preparation Process) This is the document that you need to review with the client.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BT050_REVIEWED_CONTRACT.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.060 - REVIEW PROJECT APPROACH WITH CLIENT
Review the project approach with the client. The project approach includes the method (Oracle Unified Method), the project site, duration, administration, infrastructure,
and workplan.
The project approach should also address areas such as incremental development specifically detailing any increment scope and contractual deliverables, blended
delivery and other project approaches.
ACTIVITY
PS.ACT.RPAC Review Project Assets with Client
Back to Top
WORK PRODUCT
Reviewed Project Approach
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Review and validate the obligations of all involved parties (that is, the
client, the implementing organization and any third-parties).
Validated Project
Parties' Obligations

2
Review the project approach including the following main areas:
Project Method(s)
Strategy
Plans
Client Organization
Acceptance
Project Administration
Project Infrastructure
Reviewed Project
Approach

3 Document all agreements, gaps and action items. Agreements, Gaps
and Action Items

4 Obtain agreement and Project Management sign-off. Signed Off Project
Approach
Confirm agreements and gaps along with any assigned action
items. Include a signature line for the client to sign-off.
Back to Top
APPROACH
This section is not yet available.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
25
Project Manager 75
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You will need the following for this task:
Prerequisite Usage
Scope, Objectives and Approach (Bid Preparation/Bid Review/Contract Preparation
Processes)
Use the Scope, Objectives and Approach to validate the project approach
with the client.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BT060_REVIEWED_PROJECT_APPROACH.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
BT.070 - CREATE PROJECT MANAGEMENT FRAMEWORK
The Create Initial Project Management Plan Framework is the last task in Bid Transition. It also marks the beginning of the Project Start Up phase. The Project
Management Framework is the first component of the Project Management Plan (PMP).
The creation of the PMP is started with the Project Management Framework in this task. The project manager creates the Project Management Framework along with the
project sponsor and other stakeholders. At this point in the project, the Project Management Framework represents the PMP at the strategic level. In fact, the Project
Management Framework can be thought of as the initial or high-level version of the PMP. Together, each of the Manage process components are discussed and the
project manager and the client agree on a high-level approach for each process.
After the Project Management Framework is created early in the Project Start Up phase, it is then used as a key prerequisite for each of the Manage process plans --
Scope Change Management Plan, Quality Management Plan, Risk Management Plan, etc. The PMP is refined in an iterative fashion through input and approval from the
various project stakeholders and subject matter experts as the project progresses. This means the PMP is not a status document but is evolved to become the project
management artifact that details the tools and approach for each of the 13 OUM Manage processes. See the figure below:
The Project Management Plan (PMP) is perhaps the single most important work product produced by the project manager. The PMP integrates all the OUM Manage
processes (Scope, Financial, Work, Risk, Staff, Quality, Configuration, Infrastructure, Procurement, etc.) into an integrated set of documents to guide project execution
through closure. The PMP sets stakeholder expectations and formally communicates, as precisely as possible, how the project will be conducted from a project
management perspective.
Whether developed as a single document or as a set of documents (e.g., one for each Manage process), each process component of the PMP must be presented to key
client stakeholders and discussed in detail during the Project Start Up phase. The client must approve and sign off on all components of the PMP.
The individual sections of the PMP are discussed in detail within the Project Start Up phase for each of the Manage process areas.
ACTIVITY
PS.ACT.RPAC Review Project Assets with Client
Back to Top
WORK PRODUCT
Project Management Framework
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Create the Project Management
Framework.
Project
Management
Framework
The basic elements of the Project Management Framework are described in this document. This
will be the foundation for the Project Management Plan to be completed in the Project Start Up
phase.
2 Review Project Management Framework
with the client and any third-party
stakeholders.
Accepted Project
Management
Framework
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Regardless of the size and nature of an engagement, the client always has an expectation of what the implementing organization (for example, Oracle) will do. Always
produce a confirmation document (which goes into more detail than the Proposal document) to clarify expectations of both sides in terms of the following:
Scope and Objectives
Approach - Phases, Tasks, work products, and Milestones
Acceptance of Oracles Work
Standards and Procedures to be followed during the engagement, including detailed Roles and Responsibilities
The Project Management Framework is developed using the Project Management Framework template. It provides the foundation for, and is a key component of the
Project Management Plan (PMP) but only presents the high level summary of each element of the full PMP that is developed during the Project Start Up Phase. For a
small project, the PMP may be a single document but for medium to large size projects it is more likely to be comprised of multiple documents and should, at a minimum,
address these areas:
Project Scope
Project Objectives
Project Approach
Project Workplan
Project Resourcing
Project Financials
Project Quality
Change Management
Configuration Management
Testing
Verification and Validation
Project Team Training Strategy
End-User Training Strategy
Communication
If the PMP is a single document, the Project Management Framework Table of Contents can be used to direct users of the PMP to the appropriate content areas of the
document as needed. If the PMP is comprised of multiple documents then the Project Management Framework should provide direction to the users as to the location of
each element of the PMP.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or
repetitive activities, tasks or task steps. If your project does not have a dedicated project
administrator, the project manager would perform these duties.
25
Project Manager Collaboratively develop the Project Management Framework. 75
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Proposal (Bid Preparation/Bid Review Cycle)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
BT070_PROJECT_MANAGEMENT_FRAMEWORK.DOC MS WORD
BT070_ABBREVIATED_PROJECT_MANAGEMENT_FRAMEWORK.PPTX MS POWERPOINT
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[SM] SCOPE MANAGEMENT
Scope definition is one of the most important aspects of managing a project or a large program. The Scope Management process identifies clear boundaries of what is to
be implemented and key work products to be produced. Not only does it define what the project will produce, but it also defines what will not be produced. Scope
Management should also be considered as a setting of expectations for the client. Project scope must be articulated with enough clarity and detail so that no one could be
confused about what the project will and will not accomplish.
Change Management is the second key component of the overall Scope Management process. The objectives of scope change management are to capture, evaluate
and approve change requests to agreed project baseline.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During the Project Start Up phase, the project manager is responsible for clearly validating (already defined in contract), documenting, gaining agreement on, and
communicating the scope of the project effort, including key work products and milestones. The project manager must describe the scope of the project in as much detail
as possible. It is important for the project manager to always keep in mind the Confirmed Business Case when determining if an area is in or out of scope. In addition, the
scope management approaches to be used over the course of the project are laid out. This information is captured in the Validated Scope, which becomes part of the
overall Project Management Plan.
Additionally, the project Manager must document, gain agreement on, and communicate a formal process for managing subsequent changes to the agreed upon scope as
they arise. This information is documented in the Scope Change Management Processes.
The project manager may need to update project scope, cost, budget, schedule and quality requirements based upon approved project changes orders. Effective project
change control is essential to complete projects on time and on budget. Approved scope changes affect the configuration of the work products.
Project Execution and Control Phase
During Execution and Control, the project manager should continue to re-confirm project scope with the customer and needs to regularly review the contract to ensure that
project scope is not being compromised.
The scope verification is not a single task performed only in the Project Start Up phase. The Manage Scope task is ongoing and is performed by the project team. When
deviations from the agreed contractual scope occur, the project manager should verify the changes with the customer. This is a continuous process throughout the
Project Execution and Control phase. Any deviation in scope needs to be quickly flagged and raised to the key stakeholders as a project scope change.
Effective scope change management is essential to complete projects on time and on budget. Use the Scope Change Management Process developed during Project
Start Up to properly integrate or postpone requests for changes to the project's scope. This process is designed to help you implement an efficient and effective method
of change control within the project management framework.
Project Closure Phase
The project managers focus during Project Closure should be to confirm project scope and objectives with the client and make certain that all project scope items have
been successfully delivered. Discuss agreed upon deviations and put closure on the project. Review contract to make certain that scope obligations have been met.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS SM.010 Define and Confirm Scope Validated Scope Y Core
PS SM.020 Develop Scope Change Management Processes Scope Change Management Processes Core
Project Execution and Control
PEC SM.030 Manage Scope Managed Scope Y Core
PEC SM.040 Manage Acceptance Managed Acceptance Y Core
Project Closure
PC SM.050 Gain Acceptance Final Acceptance Certificate Y Core
PC SM.060 Close Scope Management Closed Scope Management Y Core
PC SM.070 Identify Future System Enhancements Future System Enhancements Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager

Project
Leads
This role is filled by project team members (e.g., business analyst, developer, designer, system architect, etc) providing input for the project
preliminary scope statement with respect to individual team tasks and preparing documentation describing the project impact: schedule, cost, time
and resources.
Client (User)
CPS Client
Project
Sponsor

CPM Client
Project
Manager
Assist in developing the Validated Scope.
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.010 - DEFINE AND CONFIRM SCOPE
The Define and Confirm Scope task addresses and documents the characteristics and boundaries of the project and its associated work products. The Validated Scope
is a key component of the Project Management Plan. The outputs from Bid Transition process are prerequisites that can be used as input to this task.
ACTIVITY
PS.ACT.VSSOS Validate Scope, Stakeholders and OCM Strategy
Back to Top
WORK PRODUCT
Validated Scope - The Validated Scope is the definition of the project and summarizes what needs to be accomplished.
The Validated Scope should be distributed to:
Project Sponsor
Steering Committee
Project Managers (client and integrator)
Project Leads
The Validated Scope is a key component of the Project Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Determine the overall business
objectives for the project.
Context Statement Document the overall business objectives of the project.
2 Determine project requirements
and work products.
Requirements and
Work Products
List which tasks and work products will be necessary to complete the project.
3 Determine project constraints. Constraints List the conditions that may limit the project team's choices, including but not limited to project budget,
release dates, resource availability, and holiday schedules.
4 Determine key project assumptions. Assumptions List any assumptions (beliefs) that are considered "real and certain," including but not limited to scope,
resources, user participation, sign-off, and issues resolution.
5 Determine functional processes. Functional
Processes
List the functional processes.
6 Identify application modules. Application Modules List the application modules.
7 Define the technical scope. Technical Scope Document the technical scope definition.
8 Define the organizational scope. Organizational
Scope
Document the organizational scope definition.
9 Define the geographic scope. Geographic Scope Document the geographical scope definition.
10 Define the conversion scope. Conversion Scope Document the conversion scope definition.
11 Define the Interface scope. Interface Scope Document the interface scope definition.
12 Define the reporting scope. Reporting Scope Document the reporting scope definition.
13 Define the customization scope. Customization Scope
Document the customization scope definition.
14 Define the workflow scope. Workflow Scope
Document the workflow scope definition.
15 Obtain approval from key
stakeholders.
Approved Validated
Scope
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
The Validated Scope statement should:
Clearly identify all application modules, enhancements, reports, interfaces, conversions and locations in scope.
Define what is out-of-scope.
Define key project assumptions as part of the scope definition.
Define how much contingency (i.e., management reserve is going to be withheld for risk, issues, problems, and unplanned work).
Document all assumptions concerning scope, resources, user participation, sign-off, issues resolution, QA.
As mentioned above, it is extremely important to document assumptions regarding scope. In addition any constraints that the project is operating under that may affect the
project's ability to achieve the scope must also be documented.
Do not include scheduled milestones in the Validated Scope.
The following is an example of a high-level product scope definition for a hypothetical HRMS project:
Module Functionality
Phase I
Delivered
DD-MM-
YYYY
Phase II
Delivered
DD-MM-
YYYY
HR Module Position Management X
HR Module Recruit Workforce - Requisitions X
HR Module Recruit Workforce - Applicant Tracking X
HR Module EEO X
HR Module Career and Succession Planning X
HR Module Salary Planning X
HR Module Variable Compensation X
Constraints
Constraints are conditions that limit the project teams choices for completing the project.
Examples of constraints are:
Project budget
Release dates
Resource availability
Holiday schedules
Pay close attention to client-related constraints. It is imperative to uncover client plans for expansion, acquisitions, or other competing projects that might impact the
current project.
Assumptions
Assumptions are those beliefs around which decisions involving the project scope were made. For planning purposes, assumptions should be considered as real and
certain. Assumptions may impact the projects scope, schedule, or cost if they turn out to be invalid.
Examples of assumptions are:
Modules or business flows will be implemented as delivered without modification
Client project team members will have ready access to all corporate policy and procedure documentation
All assumptions concerning scope, resources, user participation, sign-off, issues resolution, QA and similar items should be documented.
Back to Top
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Siebel Customer Relationship Management (CRM)
This task has supplemental guidance that should be considered if you are doing a Siebel CRM implementation. Use the following to access the task-specific supplemental
guidance. To access all Siebel CRM supplemental information, use the OUM Siebel CRM Supplemental Guide.
SOA Engineering Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Engineering
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA
Engineering Planning Supplemental Guide.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
10
Project Manager Develop the preliminary Validated Scope. 60
Project Leads This role is filled by project team members (e.g., business analyst, developer, designer, system architect, etc) providing input
for the project preliminary scope statement with respect to individual team tasks.
30
Client Project Sponsor Authorize project activities and approves project scope and definition. *
Client Project Manager Assist in developing the Validated Scope. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Confirmed Business Case (BT.020)
Project Management Framework (BT.070)
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Pair-Choice Priority This technique provides guidance in prioritization. It includes an MS Word template that can be used to assist in prioritization.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM010_VALIDATED_SCOPE.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.020 - DEVELOP SCOPE CHANGE MANAGEMENT
PROCESSES
Scope creep kills. First it kills the budget. Then it kills the schedule. Finally it kills the project.
The objective of the Develop Scope Change Management Processes is to develop and document the various processes (procedures) for managing change during the
project. These processes include but are not limited to the following:
managing, assessing and approving change requests to established baselines
communicating approved and implemented changes to the stakeholders
updating project scope, cost, budget, schedule, and quality requirements based upon approved project scope changes
configuring work products
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Scope Change Management Processes - The Scope Change Management Processes documents the various processes (procedures) for managing change during the
project. It includes the following components:
Change Request Process
Identification Process - how to identify that a change needs to occur or has occurred
Review/Assessment Process - this is the procedure for reviewing change requests (for example, Change Request Board, Change Control Board)
Approval Process
Management Process
Reporting Process
Tracking Process
Change Request Form - used to capture individual change requests
Change Control Log - used to track the status of all change requests
who is logging the request
detailed functional and/or technical description of the requested change
description of the project impact and priority
cost and schedule impact adjustments to Project Workplan and Financial Management Plan
resource impact adjustments to Resource plan
approval/escalation process (for example, who is responsible for approving/rejecting proposed project changes (project manager/client project manager,
other roles and responsibilities, are any changes automatically approved without review, etc.)
Contract Update Process
Project Management Plan Components Update Process
Roles and Responsibilities
Back to Top
TASK STEPS
You should follow these steps
No. Task Step Component Component Description
1 Define the process for managing, assessing,
approving change requests.
Change Request
Process
Define this process in detail. Be sure to include:
Identification Process
Review/Assessment Process -- who and how
Approval Process -- who and how
Management Process
Reporting Process
Tracking Process
2 Create or obtain a change request form. Change Request Form This form is used to capture individual change requests. Include the following:
who logged the request
detailed technical/functional description of the change
cost impact (Financial Management Plan)
schedule impact (Project Workplan)
resource impact (Resource Plan)
approval/rejection section
3 Create or obtain a change request log. Change Request Log This log is used to track all change requests.
4 Define the process for updating the contract. Contract Update
Process
Define the process for updating the contract for approved change requests.
5 Define the process for updating any Project
Management Plan components, if necessary, for any
approved scope changes.
Project Management
Plan Components
Update Process
Define the process for updating any Project Management Plan process
components (for example, Financial Management Plan, Project Workplan, etc.)
for approved change requests.
6 Define roles and responsibilities. Roles and
Responsibilities
List any and all roles involved and describe the responsibilities.
7 Obtain key stakeholder agreement and approval on
the Scope Change Management Processes.
Approved Scope
Change Management
Process
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Proposed changes can require new or revised cost estimates, schedule activity sequences, schedule dates, resource requirements and analysis of risk response
alternatives. These changes can require adjustments to any of the components of the Project Management Plan (e.g., Validated Scope, Financial Management Plan,
Project Workplan, etc.) or other project work products. Any deviation in scope needs to be quickly flagged and raised to the key stakeholders as a project scope change.
Effective project change control is essential to complete projects on time and on budget. Scope Management is the process used to properly integrate or postpone
requests for changes to the project's scope.
Develop Scope Change Management Process that implement an efficient and effective method of change control. Consider the following:
Use Change Request Forms and Log to track change requests and change orders from creation, through necessary approvals, to implementation.
Control and update the scope, cost, budget, schedule, and quality requirements based upon approved changes, by coordinating changes across the entire project
and configuration.
Maintain the integrity of baselines by releasing only approved changes for incorporation into project products or services, and maintain their related configuration
and planning documentation.
Influence the factors that circumvent integrated change control so that only approved changes are implemented.
No work should be initiated unless key stakeholders have agreed to the scope change and have signed-off. Ensure that key stakeholders (for example, client executive
sponsor, key IT and business stakeholders, any partner senior executives and project sponsor are part of the Scope Change Management Processes and Change
Control Board.
Proposed changes can require new or revised cost estimates, schedule activity sequences, schedule dates, resource requirements and analysis of risk response
alternatives. These changes can require adjustments to the project management plan, project scope statement, or other project work products. Any deviation in scope
needs to be quickly flagged and raised to the key stakeholders as a project scope change. Effective project change control is essential to complete projects on time and
on budget. Scope change management is the process used to properly integrate or postpone requests for changes to the project's scope. This plan is designed to help
you implement an efficient and effective method of change control within the project management framework.
No work should be initiated unless key stakeholders have agreed to the scope change and have signed-off.
It is recommended that all changes be documented, including those that do not have a financial or schedule impact.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks
or task steps. If your project does not have a dedicated project administrator, the project manager would perform these
duties.
10
Project Manager Prepare documentation describing the project impact: schedule, cost, time and resources. 70
Project Leads This role is filled by project team members (for example, business analyst, developer, designer, system architect, etc.)
preparing documentation describing the project impact: schedule, cost, time and resources.
20
Client Project Sponsor Review and approve changes to the project scope. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Validated Scope Statement
(SM.010)

Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Scope Change Management requirements that should be taken into
consideration when developing the detailed Scope Change Management Processes.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM020_CHANGE_REQUEST_PROCESS.DOC MS WORD
SM020_SCOPE_CHANGE_MANGEMENT_CHECKLIST.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.030 - MANAGE SCOPE
In the Manage Scope task, you put into practice the processes documented in the Scope Change Management Processes and manage any possible scope changes
(Change Requests) as defined. This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MSAA Manage Scope, Acceptance and Approvals
Back to Top
WORK PRODUCT
Managed Scope - Managed Scope is the execution of the Scope Change Management Processes. Scope changes are identified, documented, reviewed, approved or
not, and as necessary, any project documentation is updated.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 As scope changes are identified, route them through the
processes identified in the Scope Change Management
Processes.
Change Request Form Once a scope change is identified, complete a Change Request Form.
2 Add each scope change (completed Change Request Form)
to the Change Request Log and track its progress.
Change Request Log Track all change requests from identification to implementation or rejection.
3 Obtain client agreement and approval and sign off on any
approved scope changes before implementation.
Change Request
Approval
Obtain any necessary sign-off to the Change Request Form or Approval
Certificate as defined in the Scope Change Management Processes.
4 Update the contract for any approved scope changes. Updated Contract Update the contract for approved change requests.
5 Update any Project Management Plan components, if
necessary, for any approved scope changes.
Updated Project
Management Plan
Components
Updating any Project Management Plan process components (for example,
Financial Management Plan, Project Workplan, etc.) for approved change
requests.
6 Implement approved scope change. Change Request Log Assign the work to the appropriate roles for completion and update the
Change Request Log to indicate resolution.
Back to Top
APPROACH
The Validate Scope and Scope Change Management Processes are developed during the Project Start Up phase and set forth the scope definition and processes for
managing scope. They should be communicated to the project team in the Scope Management Presentation made during the Team Orientation Meeting. Refer to the
Conduct Team Orientation task (STM.050) for more information on the Team Orientation Meeting. During the Team Orientation Meeting, the Validated Scope and Scope
Change Management Processes should be made available to all project team members to make sure they understand the scope of the project and the scope of their
tasks as well as the dangers of scope creep.
One of the main reasons for missing project schedule deadlines and cost overruns is scope creep unauthorized work that is outside of the projects scope. The
additional work is often undertaken for positive reasons (ease of use, added value, goodwill), but the fact that it was not approved increases the chance that it will not fit
with the projects big picture goals. A good example is the introduction of a seemingly innocent customization that blossoms into a much larger undertaking. All work
should only be included once the impacts have been understood and formally accepted by the key stakeholders and the Change Request Board.
Use the Project Workplan to manage the scope.
Any deviation in scope needs to be quickly flagged and raised to the customer as a project scope change.
Any scope change must then be documented according to the Scope Change Management Processes (including a cost/schedule impact analysis).
No work should be initiated unless the key stakeholders have agreed to the scope change and have signed off.
For approved change requests be sure to update the Project Workplan, Resource Plan, and Finance Management Plan to reflect the change. Add the new tasks, assign
resources, level the plan if necessary, and baseline the additional tasks. Do not re-baseline the entire plan or you will lose your variances.
Some guidelines to help avoid the introduction of creep include:
Be sure that the entire project team knows the baseline scope of the project.
Be sure that the entire project team is aware of the Scope Change Management Processes. This reduces the probability of an unauthorized change being made.
Regularly review the Validated Scope to ensure that project scope is not being compromised and review it with the project stakeholder.
Ensure that all project team members (client and implementers) are alert to detecting deviations in scope and report any deviations to project management.
Project management should review all proposed changes in scope in terms of the overall project impact; including any impact on the business objective for
undertaking the project.
Document all scope changes including those with no resource implications. Take a comprehensive view of scope changes in terms of impact on the overall
solution, the project schedule, resource level, client business objectives and related projects and tasks.
Be careful not to extend the scope of the project by agreeing to changes verbally.
Do not start any of the proposed work unless the client has agreed to the scope change and has signed off.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Ensure that all scope changes go through the Scope Change Management Processes. 85
Client Project Sponsor Approve change requests recommended by the Change Request Board. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Validated Scope (SM.010))
Scope Change Management Processes
(SM.020)
The Scope Change Management Processes documents the strategy and processes for managing scope change during
the project.
Orientation Guide (STM.040)
Oriented Team (STM.050)
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Scope Management.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM030_CHANGE_REQUEST_FORM.DOC MS WORD
SM030_CHANGE_REQUEST_LOG.XLS MS EXCEL
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.040 - MANAGE ACCEPTANCE
As part of the Scope Management process, acceptance must be managed. At the end of a project phase or increment, meet with the project executive sponsor (and other
stakeholders as appropriate) and make sure that the project scope and objectives have been met. Gain acceptance from the project sponsor on the completed work
products. As a precaution, make sure that acceptance is documented on all outstanding project work products.
ACTIVITY
PEC.ACT.MSAA Manage Scope, Acceptance and Approvals
Back to Top
WORK PRODUCT
Managed Acceptance
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
Component
Description
1 Complete the Acceptance Criteria for the work products completed for the given increment or phase. Acceptance
Criteria

2 Meet with the client and make sure that the project scope and objectives have been met. Gain acceptance from the client on the
completed work products. As a precaution, make sure that client acceptance is documented on all outstanding project work products.
Acceptance
Certificate

Back to Top
APPROACH
Complete the Acceptance Criteria for the work products completed for the given increment or phase. Schedule a meeting with the project sponsor to discuss the project,
review the Acceptance Criteria and sign the Acceptance Certificate. Review the contract to make certain that scope obligations are being met. Discuss all agree upon
deviations. Be sure to:
Review the contract to make certain that all contractual obligations are being met.
Ensure that all sign-offs have been received to this point in the project.
For Fixed Price projects, ensure that the Final Acceptance Certificate(s) for the milestone in the Project Workplan or the milestone in a milestone payment plan is
presented to the customer, signed, and submitted to finance, operations, and contracts for processing according to the contract payment milestone schedule.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Validated Scope (SM.010))
Scope Change Management Processes
(SM.020)
The Scope Change Management Processes documents the processes for managing acceptance during the
project.
Orientation Guide (STM.040)
Oriented Team (STM.050)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM040_ACCEPTANCE_CRITERIA.DOC MS WORD
SM040_ACCEPTANCE_CERTIFICATE.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.050 - GAIN ACCEPTANCE
As part of Project Closure, meet with the accepting organization and make sure that the project scope and objectives have been met. Gain acceptance from the
authorized individual for the overall project. As a precaution, make sure that authorized acceptance is documented on all outstanding project work products. This task can
be executed at the end of a defined increment of work, such as the end of an iteration (or Scrum sprint) or project phase.
ACTIVITY
PC.ACT.GA Gain Acceptance
Back to Top
WORK PRODUCT
Final Acceptance Certificate
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
Component
Description
1 Meet with the authorized approver and make sure that the project scope and objectives have been met. Gain acceptance from
authorized individuals on the overall project. As a precaution, make sure that authorized acceptance is documented on all outstanding
project work products.
Final
Acceptance
Certificate

Back to Top
APPROACH
Schedule a meeting with the project sponsor (and any other authorized signatories) to discuss the project and sign the Final Acceptance Certificate along with any other
closure documents (for example, closure letter, sign-off letter, etc.). Review the contract to make certain that scope obligations have been met. Discuss all agreed upon
deviations. Be sure to:
Review the contract to make certain that all contractual obligations are met.
Verify with the team that work is ready to be submitted to the authorized individuals for sign-off.
Have tests been done?
Is the required documentation available?
Are there any open issues or problems?
Submit the deliverables/work products and begin Acceptance process immediately during/after the review or walkthrough of the work being submitted.
Plan to answer questions and prioritize any issues that impede completion of the process and assist the signatory in accepting.
Offer guidance to the signatory on acceptance to make the process more efficient and effective.
The accepting organization is often responsible for the acceptance test, but they may require assistance and guidance.
Review and agree upon the list of acceptance issues.
The acceptance period refers to the period until the accepting organization completes acceptance testing and results have been delivered.
Perform rework to resolve the issues, if necessary.
Ensure that all sign-offs have been received.
Ensure the signatory has authority to sign.
If there are open items, escalate to project sponsor and add to Issues Log to monitor until closed (approved/accepted).
For Fixed Price projects, ensure that the Final Acceptance Certificate(s) (for example, the last milestone in the Project Workplan or the last milestone in a milestone
payment plan) is presented to the signatory, signed, and submitted to the appropriate organizations (such as finance, operations, and contracts) for processing according
to the agreed upon contract payment milestone schedule.
Project Acceptance Report
It is recommended that a Project Acceptance Report be produced. The purpose of the Project Acceptance Report is to provide a perspective on the project and the
overall success of implementation. The objective of the review is to assess progress toward project goals, financial goals and identity any required follow-on activity.
Review Project Objectives - This section should re-state the project objects and provide some qualitative assessments as to how the project results compared to
the project objectives.
Review Project Statistics - This section should provide some qualitative assessments and quantitative representations regarding some key project indicators.
Review Project Budget - This section should provide some qualitative assessments and quantitative representations regarding the financial health throughout the
project lifecycle.
Review Project Test Results - This section should present a synopsis of the results for the test cycles (systems, integration, and user) executed throughout the
project lifecycle.
Review Project Issues - This section provides a summary of the issues encountered throughout the project lifecycle, with the exception of post go live activities.
Please make sure to identify all open issues, where ownership needs to be transferred to the operational sustaining organization.
Review Project Risks - This section should summarize the risks encountered throughout the project lifecycle, with the exception of post go live activities.
Review Project Milestones - This section should provide a cumulative summary of the project milestones presented in the weekly status report. Please note that all
milestones detailed below have received signoff that can be found in the project diary.
Future Recommendations - This section should provide some general recommendations that should be considered for future projects.
Future Projects - This section should provide a listing of the potential future projects, which have been identified through the MoSCoW List, change request log or
through conversations with the project team members and process owner.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM040_ACCEPTANCE_CERTIFICATE.DOC MS WORD
SM050_PROJECT_ACCEPTANCE_REPORT.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.060 - CLOSE SCOPE MANAGEMENT
The Close Scope Management task is executed in the Project Closure phase. It is a clean-up task to close or transition any open change requests and archive any
documentation.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Scope Management
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Close any open change orders. Change Request Log
2 Transition any deferred Change Requests or items
to the client.
Change Request Log
3 Document any lessons learned. Scope Management Lessons
Learned
This report is used to create the Lessons Learned report produced in the
Communication process.
4 Ensure that all documentation is organized and
archived.

Back to Top
APPROACH
To obtain closure on the project, be sure to:
Close all open change orders.
Transition any deferred change request or items to the client.
Ensure that all documentation and records, physical or electronic, are systematically reviewed, organized, archived and deliver to the client, as required.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM060_SCOPE_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
SM.070 - IDENTIFY FUTURE SYSTEM ENHANCEMENTS
In this task, you identify opportunities for enhancing the system in the future. You may identify opportunities and challenges and propose a future direction for new
improvements.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Future System Enhancements
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Review Open Issues List Issue Log
2 Review Lessons Learned Lessons Learned
3 Examine Industry Trends Future Business Directions
4 Propose Future Business Direction Future Business Directions
5 Consider Open Enhancement and Change Requests that were considered out of scope Business Process Enhancements
6 Summarize Recommendations Executive Summary
Back to Top
APPROACH
Looking forward, you should consider the new features planned for the system.
You may be in an industry that has undergone some dramatic changes. If so, then it is likely that the future business direction must be in line with these changes or be
able to absorb them. For example, if there is an outsourcing trend in forward distribution, then you might want to consider the benefits and costs of implementing such a
program. Collecting industry trends can be based on obtaining general knowledge or a detailed analysis of books and periodicals.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
SM070_FUTURE_SYSTEM_ENHANCEMENTS.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[FM] FINANCIAL MANAGEMENT
Once a project price has been agreed between the client and the service provider, financial expectations have been set. The project manager must now meet these
expectations and report on the financial metrics to the client and service provider stakeholders as required by the project reporting strategy and stakeholder procedures.
In order to control costs and provide a basis for financial monitoring and reporting, the project manager needs to plan the project costs in detail.
Financial Management is heavily dependent on the Scope, Staff, Quality and Work Management processes. The financial details are not necessarily shared in a client in a
fixed price situation.
Key aspects of the Financial Management process are:
Tracking actual spend against budget (typically obtained from the service provider's financial system and/or the Project Workplan)
Developing a realistic forecast to completion (from the approved project schedule and Resource Plan)
Calculating actual and realistic forecast margin
Note: Financial Management does not usually address tracking client costs.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During the Project Start Up phase, the project manager is responsible for confirming the project finances (with key stakeholders), establishing the financial baseline and
defining the processes for managing project finances. These include:
A cost burdened project plan that correlates to the project budget
A labor and expense task structure (set up in the service provider's financial system and/or the Project Workplan) to track costs in line with procedures
A process for tracking and reporting financial performance internally and performance metrics to the client
A process for updating the Financial Management Plan based on approved change orders
A process for how invoices will be processed by the client and tracked to payment
Project Execution and Control Phase
During the Project Execution and Control phase, the project manager is responsible for tracking and controlling project effort and expenses according to the processes
established in the Project Start Up phase. These need to be managed closely and reported to the client and the service provider stakeholders. Key activities in this phase
typically include:
Entering and approving project expenses
Tracking actuals for project labor and expenses, including sub-contractors in service provider's financial system and/or the Project Workplan and Resource Plan
Updating the project schedule and Resource Plan and forecasting the financial position at project completion including any exposure on the part of service provider
and/or the client.
Performing an earned value analysis to track cost and schedule performance
Keep in mind that you need to keep track of the project costs independent of the project funding/financing but need to be in control of both.
The following data elements are typically tracked (as a minimum)
Standard rates, discounts, and actual rates for each consultant
Other project costs
Travel and expenses
Nonbillable time and expenses
A key component of successful Financial Management is the capability to compare planned achievements with actual accomplishments. Earned value analysis is the
accepted approach to achieve this.
These guidelines provide the opportunity to develop cash flow schedules, if required.
Scope changes impact cost. The successful management of project scope contributes directly to controlling project costs. Scope creep is a common cause of budget
overruns unless increases in project scope are accompanied by additional funding to perform new activities. This is an important reason why an approved project scope
is one of the fundamental building blocks of documented in the Project Management Plan.
Forecasting
Forecasting has always been a difficult concept for project managers. Because project managers focus on the success of their project, they tend to be optimistic about
the potential outcomes. This does not mean that they are not realists, but it does mean that they tend to think of the glass as being half full, rather than half empty since
both descriptions are equally accurate.This view tends to color their forecasts, sometimes at the expense of the hard truth. Accurate forecasts are essential to
establishing credibility which is an essential block of successful project management.
Project Closure Phase
During the Project Closure phase, the project manager is responsible for reconciling and closing all project finances and providing final reporting. The final actuals are
compared to the original budget as a measure of project financial performance. Activities include:
Closing out Financial Management Plan
Obtaining payment on any outstanding invoices
Closing the project entry on the service provider's financial system and/or the Project Workplan
Providing final financial reports to the client and the service provider stakeholders
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS FM.010 Refine Project Budget Approved Project Budget Y Core
PS FM.020 Develop Financial Management Plan Financial Management Plan Y Core
PS FM.030 Set Up Time and Expense Tracking Time and Expense Tracking Core
Project Execution and Control
PEC FM.040 Manage Project Finances Managed Project Finances Y Core
Project Closure
PC FM.050 Close Project Financials Closed Project Financials Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager

TM Team
Members
Accurately track time and expenses and submit them on time.
Client (User)
CPS Client
Project
Sponsor

CPM Client
Project
Manager

Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
FM.010 - REFINE PROJECT BUDGET
Using the preliminary budget information from the Bid Transition process as a starting point, refine the project budget based on additional information now available.
ACTIVITY
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
WORK PRODUCT
Approved Project Budget
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Gather any necessary documentation. None The following documentation is
needed:
Validated Scope
Baseline Project Workplan
WBS
activity resource estimates
labor categories and associated
labor rates
cost of non-labor resources.
2 Obtain and apply the rates to derive the labor budget that relates to the planned effort and
resources required to perform the project.
Labor Budget
3 Calculate a project non-labor expense budget. Non-Labor Expense
Budget

4 Validate the budget. Project Budget
5 Cost burden the Project Workplan. Cost-Burdened Project
Workplan

6 Obtain approval from key stakeholders. Approved Project
Budget
Obtain any necessary sign-off or
Approval Certificate.
Back to Top
APPROACH
The costs for schedule activities are estimated for all resources that will be assigned to the project. This includes, but is not limited to, labor, materials, allowance or a
contingency cost. A project estimate in a budget is a quantitative assessment of the likely costs of the resources required to complete the schedule activity.
Cost estimates can benefit from refinement during the course of the project to reflect the additional detail available. The accuracy of a project estimate will increase as the
project progresses through the project lifecycle.
Typically, a budget has been established and reviewed during the Bid Transition Process. This budget now needs to be refined and calculated in line with the detailed
Validated Scope and Baseline Project Workplan developed.
1. Develop and agree to the project budget.
Review the Validate Scope and the Baseline Project Workplan that reflects the planned staffing. Obtain the WBS, activity resource estimates, labor categories and
associated labor rates and cost of non-labor resources.
Obtain and apply the rates to derive the labor budget that relates to the planned effort and resources required to perform the project.
Calculate a project non-labor expense budget. Expense caps must be represented in the expense budget.
Include budget allocations for offshore and onsite resources if they are included in the project.
There is more flexibility in time and materials projects; however, the project budget should be allocated in key areas (e.g., budget by phase, budget by module/flow,
budget by work effort type functional, technical, DBA).
2. Obtain formal written approval on the budget from the key stakeholders and escalate if there are any concerns.
If you run into budget problems consider the following tips:
More senior consultants carry higher rates but should also have the implementation skills and experience to complete work more rapidly. Consider reducing effort
estimates on key tasks when there is a more senior resource.
Look for schedule gaps where a resource is not assigned full-time to a task for a short period. This dead time between activities for specialized resources is often poorly
utilized and adds to project costs unnecessarily. Find tasks assigned to heavily utilized resources and assign them to resources with gaps in their schedule. This can
result in a significantly improved schedule without incurring any additional cost.
Try reducing initial project scope. One approach is to divide the initial scope of the project into two or more phases. Discuss phasing options with your customer. Each
phase will have costs and benefits. What can they afford and where can they spend their money to get the most out of their investment? Accelerate project components
with a higher ROI and use the savings to justify funding for later phases.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Accepted Project Budget (BT.040) Use the Accepted Project Budget as the starting point.
Validated Scope (SM.010)
Baseline Project Workplan (WM.010)
The budget needs to be refined and calculated in line with the detailed Validated Scope and Baseline Project Workplan.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
FM.020 - DEVELOP FINANCIAL MANAGEMENT PLAN
The objective of the Develop Financial Management Plan task is to develop and document the strategy and processes (procedures) for managing finances during the
project. The Financial Management Plan is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Financial Management Plan - The Financial Management Plan documents the strategy and processes (procedures) for managing finances during the project. The
Financial Management Plan is a key component of the Project Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 State the financial strategy for the project. Financial Management Strategy. Document the strategy.
2 Determine the expense policies and reporting
procedures.
Project Expense Policy and
Reporting Process
Document the expense policies and reporting procedures.
3 Determine the process for invoices and payment
tracking.
Invoices and Payment Tracking
Process
Document the process for invoices and payment tracking.
4 Develop a system for tracking pertinent project
financial information.
Financial Tracking System Document the tracing system. Use a spreadsheet approach to track various
project financial information.
5 Determine reporting requirements and
guidelines.
Financial Reporting Requirements
and Guidelines
Document reporting requirements and guidelines.
6 Compile components into one document. Financial Management Plan
7 Obtain approval from key stakeholders. Approved Financial Management
Plan
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Develop and document the Financial Management strategy and processes in the Financial Management Plan. Once the Approved Project Budget has been refined, the
specific financial reporting metrics and the corresponding support process's and systems must be developed and agreed on with the key stakeholders.
Develop the Project Expense Policy and Reporting Process. Consider the following:
Expenses that are re billable to the client and any supporting documentation required by client - Sometimes clients want to review receipts. (The project manager
should confirm this with the client.)
Expense constraints (e.g., per diem, preferred hotels, rental car usage, etc.)
While the policy is part of the Financial Management Plan, you may also want to include it in the Orientation Guide for team members.
Develop the Invoices and Payment Tracking Process. Consider the following:
The project manager may be responsible for tracking payment of client invoices. Non-payment of invoices can indicate project issues.
Fixed price projects require Acceptance Certificates to be signed by the client.
Invoices should be reviewed prior to submission.
Establish the project Financial Tracking System. At a minimum, the system should:
Track all actuals numbers against budget, forecast, including variances.
Track all actuals for individual human resources on a week by week basis.
Calculate project totals for all numbers on a week by week basis.
Track all actuals against fiscal boundaries (months, quarters, years).
Track standard costs (with up lifts represented).
Forecast cost and T&E through project completion.
Track invoiced and paid labor and expenses by invoice number.
Develop any of the Financial Reporting Requirements and Guidelines (client and internal).
Compile the above components into the Financial Management Plan and gain acceptance from key stakeholders.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Cient Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Financial Management requirements that should be taken into
consideration when developing the detailed Financial Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
FM020_DEVELOP_FINANCIAL_MANAGEMENT_PLAN.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
FM.030 - SET UP TIME AND EXPENSE TRACKING
Determine and document the approach for time and expense tracking. The project team and the client may have different time and expense tracking requirements.
Develop a system that will satisfy both requirements.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Time and Expense Tracking
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
Component
Description
1 Establish or confirm local policies and procedures for time and expense tracking.
2 Verify that the project is funded properly (labor and expenses) in the relevant company financial systems (in Oracle Corporation this
would be Oracle Project Accounting).

3 Verify that services invoicing processes are in place for the Oracle, client and sub-contractors.
4 Develop and agree to a policy for use of non-billable codes, if required.
5 Define labor and expense tasks for recording actuals in accordance with project requirements and procedures.
6 Work with operations to set up labor tasks.
7 Assign project resources to labor and expense tasks and notify the resources.
Back to Top
APPROACH
At a minimum, the following should be established:
the project week span - Will reporting be done Sunday through Saturday or Saturday through Friday?
the format and location of time sheets
the due date for time sheets
the method and timing for reporting expenses totals to the project manager and the expense approval process
the approvals required before performing work on a non billable basis
the project's overtime policies
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Financial Management Plan (FM.020) The Financial Management Plan documents the strategy and processes (procedures) for managing finances during the project.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
FM030_EXPENSE_TRACKING_SPREADSHEET.XLS MS EXCEL
FM030_PROJECT_TEAM_TIME_SHEET.XLS MS EXCEL
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
FM.040 - MANAGE PROJECT FINANCES
In the Manage Project Finances task, you put into practice the processes documented in the Financial Management Plan and the Time and Expense Tracking and
manage the financial aspects of the project. Project team members should provide the project manager with a weekly update for every task assigned to them. They
should provide the actual time spent on each task during the past week and an estimate of the remaining time necessary to complete each one. This is a good way to
measure the progress of an activity while it is in progress and is essential for proper forecasting. This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MPF Manage Project Finances
Back to Top
WORK PRODUCT
Managed Project Finances
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Report Finances weekly. Weekly Finance Report
2 Report Finances monthly. Monthly Finance Report
Back to Top
APPROACH
Microsoft Project can be used to capture actual project costs and compare them to baseline (budgeted) costs by assignment, resource, or task. For Earned Value
Analysis, the three values of interest are the Actual Cost, Planned Value, and Earned Value. Microsoft continues to use the old acronyms for these values, so you find
Actual Cost in the ACWP field, Planned Value in the BCWS, and Earned Value in the BCWP field. These three values allow you to determine and report the most useful
information from the Earned Value Analysis process. However you must set up your plan differently for fixed price vs. time and materials projects in order to get the
numbers you need.
For time and materials projects you need to to:
1. Assign at least one resource to every task (except summary tasks and milestones).
2. Assign a standard rate to every resource.
3. Resource level your plan.
4. Save the project baseline.
For fixed price projects you need to:
1. Assign at least one resource to every task (except summary tasks and milestones).
2. Assign every resource a standard rate of zero (yes, zero!).
3. Structure your work breakdown so that every billing event is represented by a summary task and enter the billing amount into the summary task's Fixed Cost field.
4. Resource level your plan.
5. Save the project baseline.
On a weekly basis:
Approve project expenses for all team members. Validate that they are submitting expenses weekly and that they are adhering to company and project expense
policies.
Maintain a record of submitted and approved expenses.
Update workplan tasks with actuals so that you can determine the Earned Value CPI (Cost Performance Index) at the project level. Looking at CPI at the individual
or summary task is less useful because small variances can cause large changes in the CPI if the number of tasks is small. If you are using Microsoft Project, use
the Resource Usage view to:
Enter Actual Work completed for each task on the resource's time sheet.
Enter Remaining Work as reported for each task on the resource's time sheet.
On a monthly basis:
Reconcile client invoices to your financial records.
Gather data on invoice payments (amounts, dates, check numbers).
Track payment of any outstanding subcontractor invoices and update financial tracking spreadsheet.
On an as-needed basis
Update budget (as well as the workplan and resource plan) to reflect any approved change orders. Track change orders separately from the original budget so that
the original budget can be compared against actuals at project completion).
Track milestone revenue against budget and get signature(s) on certificates of acceptance for any completed milestone. Send signed Acceptance Certificates to
Operations, Finance and Contracts for processing.
Report project financials according to approved reporting guidelines.
When you identify cost overruns, address them a soon as possible. The longer you wait to make necessary adjustments the more restricted your options become. If you
have done a good job creating estimates and monitoring performance, the reasons for schedule problems and cost overruns should be easy to explain. The idea is to
identify and deal with small issues early instead of letting them turn into large problems.
You should always make your manager aware of any serious cost overruns and how you intend to handle them. How you raise cost overrun issues with the client will
partly depend upon your relationship with them. It is often beneficial to informally discuss the situation with key client managers and the project sponsor to get their
guidance before you develop your formal recommendation. Be prepared to offer suggested alternatives, such as substituting personnel or phasing in functionality. If the
situation requires logging an issue or problem, use the appropriate issue/problem form and the process outlined in the Issue and Problem Management System. If the
solution affects scope, complete the Change Request Form and initiate the processes outline in the Scope Change Management Processes. Be sure to follow up with
formal issues reporting that identifies the cause and contains options that show the impacts to schedules, scope, personnel, and costs. The project Steering Committee
should also be informed of the situation.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
10
Project Manager Gather time sheets and enter the data into the workplan. Perform cost performance analysis. Report deviations from financial
plan.
40
Team Members Accurately track time and expenses and submit them on time. 50
Client Project Sponsor *
Steering Committee
Member
Approve remedial efforts to address financial variances, whether by approving additional budget or personnel changes. *
Client Project Manager Review financial reports and participate in addressing variances. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Financial Management Plan (FM.020) The Financial Management Plan documents the strategy and processes (procedures) for managing finances during the project.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Metrics for Agile Projects Use this technique to measure actual budget expended against what was planned for agile projects.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
FM.050 - CLOSE PROJECT FINANCIALS
During Project Closure, the project manager is responsible for reconciling and closing out all project finances and producing final reports.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Project Financials
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Update final task status to the Project Workplan. Closed Project Workplan
2 Enter remaining T&E to Time and Expense
Tracking System.
Closed Project in T&E System
3 Run final T&E reports. Final T&E Reports
4 Reconcile outstanding vendor invoices. Closed Vendor PO
5 Enter final updates to financial tracking
spreadsheet.
Final Financial Tracking
Spreadsheet

6 Document any lessons learned. Financial Management Lessons
Learned
This report is used to create the Lessons Learned report produced in the
Communication process.
7 Produce final financial reports. Final Financial Reports
Back to Top
APPROACH
Compare the final actuals to the original budget as a measure of assessing project financial performance.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Make final updates to tracking documents and produce final reports. 85
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
FM050_FINANCIAL_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[WM] WORK MANAGEMENT
The Work Management process focuses on the following:
develop the Project Workplan
define and document the processes and policies to be used to execute, maintain, control and close-out the Project Workplan
manage team work
close out team work activities and the Project Workplan and provide final project financials
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During the Project Start Up phase, the project manager is responsible for clearly defining, documenting, gaining agreement on, and communicating the Project Workplan
as well as the Work Management Plan that defines the control processes and policies to be used to execute and control the Project Workplan. Processes and policies
that should be discussed in the Work Management Plan include the following:
Developing the Baseline Project Workplan
Controlling the Workplan through the life cycle of the project.
Executing the Workplan
Managing Team Work
Managing Team Time
The Project Workplan is the hub of Project Management as it denotes all the tasks and activities to be performed by the team within the projects scope, objectives, and
approach and it provides a repository of data that the project manager can utilize to plan the project. A project planning tool must be used for developing, maintaining,
managing and closing out the Project Workplan.
Project Execution and Control Phase
During the Project Execution and Control phase, the project manager is responsible for managing team work and controlling and executing the Project Workplan. The
project manager would typically collaborate with the client project manager to manage client team work.
Project Closure Phase
During Project Closure, the project manager is responsible for closing out team work activities and the Project Workplan and for providing final project financials.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS WM.010 Develop Baseline Project Workplan Baseline Project Workplan Y Core
PS WM.020 Develop Work Management Execution and Control Processes and Policies Work Management Plan Y Core
Project Execution and Control
PEC WM.030 Manage Project Workplan Project Workplan Y Core
PEC WM.040 Track Schedule Performance Schedule Performance Y Core
PEC WM.050 Manage Approvals Managed Approvals Y Core
Project Closure
PC WM.060 Close Work Management Closed Work Management Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager

Project
Leads
This role is filled by project team members (for example, business analyst, developer, designer, system architect, etc) providing expert advice.
Client (User)
CPS Client
Project
Sponsor

Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
WM.010 - DEVELOP BASELINE PROJECT WORKPLAN
In this task, you determine, organize, estimate, link, and schedule all of the tasks representing the work to be performed on the project and organize them into the
Baseline Project Workplan. This task can be performed with varying degrees of scope, rigor, and detail, depending on the circumstances in which it is used. It can be
used for forecasting, estimating, planning and impact analysis. You can use the Work Breakdown Structure (WBS) created during the Bid Transition process (if available)
or any of the example workplans found in the Key Component sections of the views as a starting point and then tailor the workplan, as appropriate for the project.
OUM encourages plans to be developed according to an approach that balances agility with discipline. This approach allows for a more agile project situation where the
system is developed through a series of mini-projects (iterative) and in smaller portions at a time (incremental), enabling the project team to take advantage of what was
learned during development of earlier parts or versions of the system and incorporate external feedback from project stakeholders. Agile projects typically follow a more
adaptable and collaborative approach.
ACTIVITY
PS.ACT.DW Develop Workplan
Back to Top
WORK PRODUCT
Baseline Project Workplan - The Baseline Project Workplan consists of the following:
An Implementation Plan that represents one full pass through all of the OUM phases. It focuses on the project objectives, milestones and the number of iterations.
An Iteration Plan that includes an Iteration Plan Summary that focuses on the scope, objectives, and approach for the first iteration of Inception and a detailed
WBS Project Workplan that provides a network of interdependent tasks representing all work, with staff work assignments and schedules.
It should be distributed to the following:
Project Manager
Project Stakeholders
Team Leads
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Create the
initial
Implementation
Plan
Implementation
Plan
The Implementation Plan is a brief, coarse-grained outline for the project. The main purpose of the Implementation Plan is to
provide a roadmap for achieving the projects goals, along with a sketch of the number and purpose of each iteration needed per
phase.
2 Create the
Iteration Plan
for the first
iteration of
Inception.
Iteration Plan
Summary
WBS Project
Workplan
The Iteration Plan is made up of the Iteration Plan Summary and the WBS Project Workplan.
The Iteration Plan Summary for the first iteration of Inception outlines the scope, objectives and approach for the iteration. As the
project progresses, an Iteration Plan Summary will be created for each iteration in the project.
The WBS Project Workplan is a detailed workplan that represents the lowest and most detailed layer of planning. You can use the
Work Breakdown Structure (WBS) created during the Bid Transition process (if available), the OUM Project Workplan, or any
other example Project Workplan that can be found in the Key Components section of some views as a starting point and then
tailor the workplan as appropriate for the project. Refer to Tailoring OUM for Your Project for an overview of the tailoring process
in OUM.
3 Refine and
baseline the
WBS Project
Workplan.
Baseline WBS
Project
Workplan
A Baseline WBS Project Workplan captures the original project data that will be utilized for tracking and reporting and for
determining project variances. It allows you to compare actual performance during the project back to the the Baseline WBS
Project Workplan.
4 Consider the
need to
partition the
WBS Project
Baseline WBS
Project
Workplan
Update the Baseline WBS Project Workplan with appropriate partitions (e.g., by product, by process, by custom work verses
configuration work, etc.). Partitions allow a project to be partitioned or divided into smaller pieces. These pieces may be
implemented serially, in parallel or staggered.
Workplan.
Back to Top
APPROACH
Overview
As shown in the figure below, there are two plans active in the project at any given time on an OUM project the Implementation Plan and the Iteration Plan.
DEFINITIONS OF PLANS AT EACH LAYER
The Implementation Plan
The Implementation Plan is a brief, coarse-grained outline for the project. The objectives for the project are reflected in the Implementation Plan and tie back to the
Business Case developed in the OUM Envision Focus Area. The main purpose of the Implementation Plan is to provide a roadmap for achieving the projects goals,
along with a sketch of the number and purpose of each iteration needed per phase.
The Iteration Plan
The Iteration Plan contains the Iteration Plan Summary and the detailed WBS Project Workplan that represents the lowest and most detailed layer of planning. An
individual Iteration Plan Summary will be created for each iteration in the project. The current Iteration Plan focuses on how an incremental set of objectives and/or
functionality will be delivered within the framework of the project. The main purpose of the Iteration Plan is to lay out how the team will achieve the stated objectives for
the given iteration.
PLANNING USING A TOP-DOWN/BOTTOM-UP APPROACH
In OUM, plans are created using a top-down/bottom-up approach in which the plans at each layer (Implementation and Iteration) are created and maintained in a
simultaneous fashion. Because the plans are inter-related, it is likely that a change to a plan at one layer will cause the need for an adjustment to a plan at another layer.
The planning layers are show in the figure below.
In the Project Start Up phase, the focus is on the Implementation Plan. Also in Project Start Up, the initial iteration of the OUM Implement Inception phase is drafted to the
degree that the project is able to move into the Inception phase.
During Inception, the Implementation Plan created in Project Start Up is further refined as more project requirements and risks are uncovered. As the project iterates
through the later phases, the plans at each layer (implementation and iteration) will be adjusted based on the results of iteration assessments and as project objectives
shift, as is often the case.
On any OUM project, an Iteration Plan for the upcoming iteration is created before that iteration begins. Also, the Implementation Plan must be examined to ensure it is
still valid as the Iteration Plans are created and maintained.
Therefore, at any time on an OUM project the following plans should be active:
One Implementation Plan
Two Iteration Plans - one for the current iteration and a draft for the upcoming iteration
In the Project Start Up phase, the focus is on the Implementation Plan. Also in Project Start Up, the initial iteration of the OUM Implement Inception phase is drafted to the
degree that the project is able to move into the Inception phase.
During Inception, the Implementation Plan created in Project Start Up is further refined as more project requirements and risks are uncovered. As the project iterates
through the later phases, the plans at each layer (implementation and iteration) will be adjusted based on the results of iteration assessments and as project objectives
shift, as is often the case.
The project manager is expected to develop, communicate and maintain a resource-leveled workplan for each project over which he/she has project management
responsibility.
Create the Initial Implementation Plan
In OUM, the Implementation Plan is an outline of the project, showing the total number of planned iterations across the five OUM phases (Inception, Elaboration,
Construction, Transition and Production) as well as key milestone dates for each of these iterations. The Implementation Plan will sketch out the work across the five
phases by outlining the number of iterations in each phase and major milestones. Using the estimates for the project and the known priorities, lay out an Implementation
Plan, mapping requirements (both functional and technical) very roughly to each projected iteration. Keep in mind that an iteration in OUM should be from two to six
weeks in length, which allows the work on the project to be broken up into manageable chunks. You may find that certain requirements pose design or architectural risks,
and should consider assigning them to earlier iterations in order to address those potential risks as early in the project as possible. A representation of a typical
Implementation Plan is shown below.
The Implementation Plan presents a roadmap of the planned iterations and should summarize the following:
Objective(s) of each iteration and its contribution to the project goal(s)
Business Milestones
Project Commitments
Team Composition
Project Dependencies
Project Approach
Factors that Drive the Number of Iterations per Phase
As part of the Implementation Planning, the number of iterations per phase will need to be determined. In general, OUM recommends using the standard number of
iterations as depicted in the OUM Implement Focus Area diagram. However, there are several factors that can increase or decrease the number of iterations represented
in the plan(s). The factors that would increase the number of iterations per phase are shown in table below.
Phase Factors
Inception
Highly variable scope
Lack of artifacts from Envision or Envision not conducted
Poorly defined / documented business objectives
Disagreement between stakeholders
Elaboration

Unstable architecture
Unproven architecture
Unstable requirements
Unavailable development environment
Challenging non-functional requirements
Construction
Large amounts of functionality to develop and test
Poor architecture
Limited team resources
Transition
Hardware replacement or rollout
Number of deployment and / or rollout sites
Large numbers of users to be trained or complex training required
Production
Level and length of support required
Incremental rollout strategy
Refer to the Determining the Number of Iterations technique below.
Before commencing work, present the plan to the stakeholders to gain agreement on the Implementation Plan. The project team in particular should agree on the
Implementation Plan.
Create the Iteration Plan for the First Iteration of Inception
Create the Iteration Plan for the first iteration of the Inception phase.
First, create the Iteration Plan Summary documenting the scope, objectives and approach for the iteration. As the project progresses, an Iteration Plan Summary will be
created for each iteration in the project.
Next, create the detailed WBS Project Workplan. It should be detailed enough to allow the project to move forward. Consider using the WBS from Bid Transition (if
available) or using any of the OUM example workplans as a starting point. To determine if a suitable starting Project Workplan template is available, review the Key
Components section of the OUM view that most closely matches the project profile. The tasks for an Iteration Plan in Inception should contribute towards goals for
meeting the Lifecycle Objective milestone that includes confirming the business objectives and project scope, determining risk, estimating cost and plan and staffing and
preparing the project team.
Once the core of the WBS Project Workplan is established, add or eliminate tasks or processes to match the identified scope and risk of the project. The next step in
building the detailed WBS Project Workplan is to consider the depth to which a particular task will be executed. Tasks in OUM are placeholders for work and are highly
scalable. Under the proper circumstances, spending the time to simply consider a task can constitute executing the task. This is a perfectly acceptable practice and is
often preferable to eliminating the task totally. Tasks are there to remind you of the process and order of the work. Finally, consider whether it is advisable or appropriate
to combine tasks or to execute the project using OUM's activities, which are groupings of tasks.
Refine and Baseline the Project Workplan
Refine the layers of the Project Workplan (that is, the Implementation Plan and Iteration Plan) for the first iteration of Inception, as necessary based on the risks and scope
information available during Project Start Up.
Although there is often uncertainty inherent in agile project, it is recommended that you baseline the Implementation Plan. The baseline provides a means for balancing
control and the requirement for responsiveness of incremental delivery. An initial baseline is created against which the team can implement change within defined
tolerances. Where change falls outside of these the Scope Change Management process is invoked. This is essential for stakeholder control and visibility. The baseline
also provides the benefits of providing an ability to track performance and the teams velocity, as well as improve future estimating capabilities.
In order to calculate the initial baseline for the Implementation Plan, 5 data points are required:
the number of planned iterations for the entire project
the length of each iteration in calendar days
the number of use cases planned for the project
the budget planned for the project
the start date of the project
Consider the Need to Partition the Workplan
In a large and/or complex OUM project, there may be a need to break up the expected functionality into partitions. This could include one for each major release of the
product to be developed, implemented or upgraded. Projects that are more than a year in duration, those with high risk factors and/or projects where there is business
value to be gained from delivery of a sub-set of the overall functionality are all candidates for the partitioned workplan approach. This approach allows risk to be spread
over a number of partitions and permits business value to be delivered sooner.
In the case where the multiple partitions will be used to accomplish the projects objectives, an overall plan should be established to map out the partitions. These
partitions may be implemented serially, in parallel or staggered. Each partition should be planned so that the delivery of some subset of the project benefits are realized
through the delivery of working software and/or implementation of Commercial Off-the-Shelf Software (COTS). This is done by examining the business drivers and
schedule goals for the project, laying out the work and assigning the milestones in the roadmap to one or more partitions.
Once the overall plan for the partitions is established, the planning details can be pushed to the lower level Implementation and Iteration Plans for each partition. As the
project progresses through the first partition and subsequent partitions, more information is brought to light that will require the plans at each layer to be adjusted.
Back to Top
SUPPLEMENTAL GUIDANCE
Iterative and Incremental Project Planning
This task has supplemental guidance for iterative and incremental project planning. Use Planning a Project using OUM - An Iterative and Incremental Approach to access
the supplemental information.
Tailoring OUM for Your Project
Refer to Tailoring OUM for Your Project for an overview of the tailoring process in OUM.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
10
Project Manager 65
Project Leads This role is filled by project team members (for example, business analyst, developer, designer, system architect, etc) providing
expert advice.
25
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Work Breakdown Structure (WBS) (Bid Process)
Validated Scope (SM.010)
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Determining the Number of Iterations Use this technique to estimate the number of iterations for each phase when developing the Implementation Plan.
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Work Management.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IMPLEMENTATION_PLAN.DOC MS Word - Use this template to create the Implementation Plan.
ITERATION_PLAN_SUMMARY.DOC MS Word - Use this template to create the Iteration Plan Summary portion of the Iteration Plan that documents the scope,
objectives and approach for the iteration.
OUM Project Workplan MS Project - Use this template to create a detailed Project Workplan as a starting point.
Scrum Project Workplan (optional) MS Project - You may choose to use this workplan if you are using a Scrum project management approach on your project.
Although, a Scrum Workplan is not an official Scrum artifact, some projects may require a Project Workplan.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
WM.020 - DEVELOP WORK MANAGEMENT EXECUTION AND
CONTROL PROCESSES AND POLICIES
Develop and document the strategy, control processes and policies that are used to manage, support and implement the work during the project. The Work Management
Plan is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Work Management Plan - The Work Management Plan documents the strategy, control processes and policies that are used to manage, support and implement the
work during the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Develop any Work Management policies
and procedures.
Work Management Polices
and Procedures
Document any policies and procedures. Include the following:
Team Time Entry Process
Task Assignment to Project Team Members Process
Task Status Reporting Process
Unplanned Activities Time Capture Process
2 Develop Project Workplan updates and
versioning procedures.
Workplan Updates and
Versioning Procedures
Document the update and versioning procedures. Include the following:
Workplan Change Procedure
Workplan Archival Procedure
3 Develop monitoring and controlling
processes.
Work Management Monitoring
and Controlling Processes
Document any monitoring and controlling processes. Include the following:
Workplan Utilization to Analyze Project Trends
Workplan Utilization to Report Project Progress
4 Develop work product approval process Work Product Approval
Process
Approval Certificate
The Work Product Approval Process includes a list of all project work products
requiring approval of sign-off and from whom. In addition, define the following:
turn-around time
process
Obtain or create Approval Certificate Form.
5 Define contingency and management
reserve strategy.
Project Contingency and
Management Reserve
Strategy
Document contingency and management reserve strategy.
6 Obtain key stakeholder agreement and
approval on the Work Management Plan.
Approved Work Management
Plan
Obtain any necessary sign-off or Approval Certificate.
7 Make Work Management Plan available to
team members and client.
Work Management Plan
Back to Top
APPROACH
Develop Work Management Policies and Procedures
Develop and document the work management processes and policies that will be used during the project execution and control phases and communicate these to the
project team and client management. These policies and processes include:
Team Time Entry Process
Task Assignment to Project Team Members Process
Task Status Reporting Process
Unplanned Activities Time Capture Process
Team Time Entry Process
Time entry may include entering time to specific milestones reflected in the Project Accounting system work breakdown structure. Assigning workplan tasks would include
assigning tasks to all project team members including the client. Utilizing milestones for time entry would facilitate earned value analysis at the milestone level using the
Project Accounting actuals. If it is planned to enter actuals into the Project Workplan, time entry would also include the project team completing a time sheet weekly
indicating how much time was spent on individual tasks. Entering of actuals to the Project Workplan facilitates earned value analysis starting at the task level through the
planning tool.
Task Assignment to Project Team Members Process
At a minimum, team members must be advised of their upcoming tasks at least two weeks in advance so that team members can plan their work schedules. A best
practice would be to develop a weekly schedule that would advise the project team as a whole including the client of the planned activities that must be completed
during a pre-determined period.
Task Status Reporting Process
Determining task status would generally reflect status based on the amount of work (hours) remaining. For example, if a task has a 40 hour baseline, 20 hours have
been spent on the task to date and the team member feels that the task can still be completed with the remaining time allocated, the task would be considered 50%
complete. However, if the team member estimates that either more or less remaining hours are needed, the task must then be re estimated. If the team member
estimates that the duration (start and end dates) does not line up to the original duration, the task must be rescheduled (and re estimated if appropriate). Task status
reporting must be performed weekly and the information would be given by the team member to the project manager at the end of the work week. The project manager
must review and approve all re estimating and rescheduling; the project managers review could result in the project manager overriding the new estimate/revised
schedule given by a team member. Feedback regarding this approval and the resulting schedule change, if any, needs to be given as soon as possible to the team
member preferably by the first day of the following work week after the status was given. The rule of thumb is that no task would have a zero estimate to complete if
the task is not completed and no task would have overdue start and end dates. A best practice would be that the team would provide task status in weekly team status
reports.
Unplanned Activities Time Capture Process
The team must work to plan any activities outside of plan need to be reported weekly by the team and tracked by the project manager. Team members need to obtain
the project managers approval before taking part in unplanned activities. If this is not possible, the team member needs to advise the project manager of the activity as
soon as feasible. The amount of work on these activities needs to be tracked and reported separately from planned work. An unplanned activity would be considered
immediately complete; otherwise it would be a change and would need to go through the Scope Change Management Processes. A best practice would be to include an
area in weekly team status reports for the team to advise of the activity performed and the amount of work (hours) performed. The project manager would log the
unplanned activity in a specified area in the Project Workplan including the resource that performed it and the amount of time spent.
Develop Workplan Updates and Versioning Procedures
Develop the procedures to control the Project Workplan consisting of the following:
Workplan Change Procedure
Workplan Archival Procedure
Workplan Change Procedure
Changes made to the Project Workplan would, as a rule, entail changes due to re-estimating, re-scheduling, re-assigning resources and applying change order tasks.
Changes due to re-estimating and re-scheduling would not be re-baselined so that the original estimate and schedule could be used for variance tracking and reporting.
Changes requiring resource re-assignment would be done by zeroing out the original resource and then adding the new resource to the task with the original resources
work remaining given to the new resource.
Changes due to applying change order tasks need to include a method to identify the change order this could be done through a text field in the plan that would be used
for this data. Change order tasks would be base lined so that the original estimate and schedule would be captured. For the most part, change orders will be customer
approved change orders.
Develop Work Management Monitoring and Controlling Processes
Document the processes to execute the Project Workplan. These processes would include but are not limited to the following:
Workplan Utilization to Analyze Project Trends
Workplan Utilization to Report Project Progress
Executing the Project Workplan would include work management as discussed above, but it also includes methods that the project manager would utilize to manage the
project to plan. These would comprise of analyzing and tracking project trends and variances based on project actuals, analyzing the projects critical path and analyzing
and reporting project progress based on the repository of information that would be collected during the execution of the plan.
Workplan Utilization to Analyze Project Trends
Analyzing project trends would usually be done by reviewing the project tasks to see how well they are being performed and project resources to see how well they are
performing. Analyzing these trends and making adjustments based on the trends is essential in keeping the team working to plan.
Determining variances in task performance and the schedule is vital in determining the projects progress to date, determining the projects estimate to complete and in
forecasting how well the project will complete. This variance analysis is typically called earned value analysis. Earned value analysis encompasses a variety of analyses
based on pre-determined algorithms that result in indicators that are applied to the projects results to date.
Workplan Utilization to Report Project Progres
Reporting project progress using the Project Workplans repository of data would include reporting progress to all those concerned with the project from the team
member to the executive sponsors. Team member progress reporting must entail progress on his/her tasks as well as on the project as a whole. At a minimum, this
information must be given to team members on a weekly basis. These progress reports would typically be given at the task level. Executive-level project progress
reports would typically be given at a higher level.
Develop Work Product Approval Process
The first step in the process is to agree on the specific project work products that require approval. It is always best to agree on these in advance to avoid surprises later.
One the list is complete, the next step is to decide who the appropriate approver is for each work product. While it might be tempting to try to assign responsibility to one
person for a whole class of work products, make sure that all of them are appropriate for that person to approve. On close inspection, some might need to have a
different person's approval. Next, define the turnaround time from the time the work product is turned over for review until an approval or deficiency notice is due back. If
possible, include a "deemed acceptance" clause in the timeline, so that if no response is received within a specified period of time, the work product is automatically
approved. Finally, define the process that the work products will go through. Will delivery be hard or soft copy? Will the "clock" start upon delivery or is a separate
notification required? What is the escalation procedure if there is a difference of opinion about the justification for a rejection notice? Once all the questions have been
answered (there are more than were mentioned here), document them and get an approval signature for the process.
The most important approval is the first one. Gain approval of the Work Management Plan. By sticking to the agreed-upon process from the beginning, you improve the
odds that there will not be a breakdown in the procedure later on, when it might be more critical. Everyone will be in the habit of working through the approval process
and it should be followed routinely.
Define Project Contingency and Management Reserve Strategy
Contingency reserve is an often misunderstood and neglected project management concept. The simple fact is contingency reserve should be included as a standard,
required project management tool on most projects.
Contingency reserve planning can be quite sophisticated and there is a substantial body of literature available on the subject. The Project Management Institute's Project
Management Body of Knowledge (PMBOK) provides an excellent treatment of the subject.
There are two terms you should be familiar with: contingency reserve (a.k.a., contingency funds) and management reserve.
Term PMBOK Definition
Contingency Funds
Contingency reserves are estimated costs to be used at the discretion of the project manager to deal with anticipated, but not certain
events. These events are known unknowns and are part of the projects scope and cost baselines.
Management Reserve
Management reserves are budgets reserved for unplanned, but potentially required, changes to project scope and cost. These are
unknown unknowns and the project manager must obtain approval before obligating or spending this reserve. Management
contingency reserves are not a part of the project cost baseline, but are included in the budget for the project. They are not
distributed as budget and, therefore, are not a part of the earned value calculations.
An easy way to remember the difference is with a simple mnemonic. Project delays and associated costs caused by snowstorms in Canada come out of contingency
funds. Project delays and associated costs caused by snowstorms in Mexico come out of management reserve.
Contingency Funds
Contingency funds should be a standard tool used by project managers to address schedule and cost-related risks. Ideally, the projects contingency funds should equal
the total of the expected cost (probability times impact) of all project schedule and cost risks and their associated risk response plans.
Management Reserve
This may also be handled by change requests.
Communicate the Work Management Plan to the Project Team
Once the Work Management Plan is developed, obtain any necessary sign-off or Approval Certificate from the client. Make the Work Management Plan available to the
project team and client.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Work Management requirements that should be taken into consideration
when developing the detailed Work Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
WM020_DEVELOP_WORK_MANAGEMENT_PROCESSES_AND_POLICIES.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
WM.030 - MANAGE PROJECT WORKPLAN
In the Manage Project Workplan task, you put into practice the strategy, processes and procedures documented in the Work Management Plan to engage resources to
execute the Work Management Plan (tasks and processes) defined in the Project Start Up phase and regularly review and update the Project Workplan with the actuals.
This task is ongoing throughout the Project Execution and Control phase by following an iterative and incremental planning approach.
As discussed in task, Develop Baseline Project Workplan (WM.010), plans are created in OUM using a top-down/bottom-up approach in which the plans at each layer
(Implementation and Iteration) are created and maintained in a simultaneous fashion. Because the plans are inter-related, it is likely that a change to a plan at one layer
will cause the need for an adjustment to a plan at another layer. At any given time in a project, there are two Iteration Plans active the one for the current iteration and
the one for the upcoming iteration. In this task, the Iteration Plan for the current iteration is monitored and maintained, the Iteration Plan for the subsequent iteration is
drafted and the Implementation Plan is adjusted as necessary based on the current and projected actual versus expected progress.
ACTIVITY
PEC.ACT.MPW Manage Project Workplan
Back to Top
WORK PRODUCT
Project Workplan - The Project Workplan consists of the following:
An Implementation Plan that represents one full pass through all of the OUM phases. It focuses on the project objectives, milestones and the number of iterations.
An Iteration Plan that includes an Iteration Plan Summary that focuses on the scope, objectives, and approach for the first iteration of Inception and a detailed
WBS Project Workplan that provides a network of interdependent tasks representing all work, with staff work assignments and schedules.
The Project Workplan is a living document that needs to be actively managed and maintained to reflect the current status and provide a realistic forecast throughout the
duration of the project. The Project Workplan is executed using the Work Management Plan. The Project Workplan consists of the following:
An Implementation Plan that represents one full pass through all of the OUM phases. It focuses on the project objectives, milestones and the number of iterations.
Various Iteration Plans, each consisting of an Iteration Plan Summary that focuses on the scope, objectives, and approach for the iteration and a detailed WBS
Project Workplan that provides a network of interdependent tasks representing all work, with staff work assignments and schedules. Each Iteration Plan is
focused on accomplishing the respective iteration's objectives and reducing risk.
The Baseline Project Workplan that was created in WM.010 is used as the starting point for the Project Workplan. It was created using a top-down/bottom-up approach in
which the plans at each layer (Implementation and Iteration) are created and maintained in a simultaneous fashion. Because the Implementation Plan and Iteration plans
are inter-related, it is likely that a change to a plan at one layer will cause the need for an adjustment to a plan at another layer.
Notice that the plan at the Implementation Plan level is longer in terms of time horizon but lower in granularity. This allows the project manager and other stakeholders to
have a roadmap view of the projects major milestones. The detailed planning is done at the Iteration Plan level that has a shorter time-horizon but more detail. This
allows the project manager and team members to have a way of planning and managing their day-to-day work.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify the objectives for the current Iteration
Plan.
Objectives,
Iteration Plan
Summary,
Iteration
Objectives
An iterations objectives and scope are defined in OUM by the set of use cases, configuration
requirements and other non-functional requirements that will be achieved during the iteration.
These requirements are selected from the projects current MoSCoW List and should be focused
on achieving the objectives of the present phase of the project.
2 Create the current Iteration Plan. Iteration Plan
for the Current
Iteration
The current Iteration Plan includes a time horizon for the next two to six weeks. It often can start
with a copy of the initial Iteration Plan (from the Baseline Project Workplan - WM.010) or the prior
Iteration Plan (depending on where you are in the project). Bring forward any work not completed
from the prior iteration and any approved change requests.
3 Towards the end of the current iteration, create
the draft plan for the upcoming iteration.
Iteration Plan
for the
Upcoming
Iteration
The upcoming Iteration Plan should start with a copy of the current Iteration Plan and is updated
for the next iteration. It evolves as the current iteration is executed. As results are known during
the current iteration, it will become apparent which tasks need to be included in the next iteration.
4 Adjust the Implementation Plan as needed. Implementation
Plan
The Implementation Plan must be kept in synch as each subsequent Iteration Plan is developed.
The degree to which an iteration achieves its objectives will impact future iterations as well as
milestones on the Implementation Plan.
5 Use the monitoring and controlling processes
documented in the Work Management Plan to
analyze the Project Workplan for variances
and trends and update accordingly.
Updated
Project
Workplan
The Project Workplan is updated for any variances and trends. Be sure to follow the update and
version procedures defined in the Workplan Change Procedure of the Work Management Plan
(WM.020).
6 Periodically, review the Implementation Plan for
the project schedule and completion estimate.
Project
Schedule and
Completion
Estimate
The Project Schedule and Completion Estimate is determined from the Project Workplan,
Resource Plan and Work Management Plan.
7 Produce Progress Reports. Various Work
Management
Progress
Reports
Various Work Management Progress Reports are produced based on the Reporting Procedures
and Reports and Schedule defined in the Work Management Plan (WM.020).
8 Ensure project team is submitting weekly time
and expense reports.
Weekly Time
and Expense
Reports
Weekly Time and Expense Reports are submitted by the project team based on the procedures
defined in the Work Management Plan (WM.020).
9 Ensure work breakdown structure (WBS) and
time entries are in synch.
Weekly Time
Entry
The Weekly Time Entry is synchronized with time entry according to the Team Time Entry Process
defined in the Work Management Plan (WM.020).
10 Enter actuals in WBS weekly for the current
Iteration Plan.
Updated
Iteration Plan
The Iteration Plan is updated weekly with actuals.
11 Assign team members to tasks. Task
Assignments
Task Assignments are given to team members according to the Task Assignment to Project Team
Members Process defined in the Work Management Plan (WM.020)
12 Communicate project status to team. Team Status
Report
The Team Status Report is communicated to the team as defined in the Task Status Reporting
Process defined in the Work Management Plan (WM.020).
13 Update task status (at least weekly). Task Status
Report
The Task Status Report is updated weekly as defined in the Task Status Reporting Process
defined in the Work Management Plan (WM.020).
14 Capture all unplanned activities. Unplanned
Activities Log
The Unplanned Activities Log is produced as defined in the Unplanned Activities TIme Capture
Process defined in the Work Management Plan (WM.020)
15 Forecast remaining work. Remaining
Work Forecast
The Remaining Work Forecast is a realistic forecast of work remaining.
16 Back up and archive Project Workplan. Project
Workplan
The Project Workplan is backed up and archived as defined and scheduled in the Workplan
Archival Procedure in the Work Management Plan (WM.020)
Back to Top
APPROACH
The Project Workplan is a living document that needs to be actively managed and maintained to reflect the current status and a realistic forecast throughout the duration
of the project. Use the strategy, control processes and policies documented in the Work Management Plan (WM.020) to manage the Project Workplan.
Iteration planning is where the bulk of planning for a project occurs. Each iteration should be planned so that a set of specific objectives are accomplished and a group of
project risks are addressed. A project manager will typically analyze and manage the current Iteration Plan on a daily basis.
The Iteration Plan information should be compiled in two documents. The first document, the Iteration Plan Summary reflects the scope and objectives of the iteration. The
primary goal of the scope is to clarify the iteration's objectives, priorities and evaluation criteria. This information can be used to track the iteration's progress and drive the
iteration assessment. The rest of the plan captures the detailed plan at the task level for the execution of the iteration.
For each iteration, the top risks should be identified based on the current state of the project (i.e., progress to-date, project phase, team experience, etc.). A rule of thumb
is to narrow the top risks to a list of no more than 10. Based on the list of the top 10 risks, the Iteration Plan can be developed to actively address each risk.
The deliverables for a given iteration should be associated with one or more of the iterations objectives. The iterations deliverables should not be confused with the OUM
task work products. The work products are just a means to an end to producing the deliverable and are not necessarily related to the projects objectives.
The most important deliverable of any iteration is the increment that will be developed. This is defined in OUM by the set of use cases, configuration requirements and
other non-functional requirements that will be achieved during the iteration. These requirements are selected from the projects current MoSCoW List. Selecting the right
set of requirements requires collaboration among all team members and should be focused on the current Ms and Ss shown on the MoSCoW list. Simply stated, the
MoSCoW List registers the known business requirements. Each requirement is classified by the first letter of: Must, Should, Could or Wont.
As the project moves along and risks are retired, the focus of the iterations can shift to filling out the needed functionality for the product under development. Also, change
requests and identified defects can be addressed as the more architecturally significant use cases have been realized. To achieve the right balance, the required
functionality, change requests and defects must be prioritized and estimated by analyzing the MoSCoW List. See task, RD.045 - Prioritize Requirements for more
information on how MoSCoW is used in OUM.
The scope of the iteration will be determined according to the objectives for the current iteration, team capacity and the iterations deliverables. These factors are
discussed in the sections below.
Objectives of the Current Iteration
Based upon the results of the risk analysis and the progress of the project up to this point must be refined to provide a clear set of measurable and achievable objectives
for the given iteration. The objectives for any iteration should be based on the current phase the project and should relate to meeting the milestone objectives for the
particular phase.
Team Capacity
The teams capacity is a broad measure of the amount of effort the team will be able to take on in the iteration. The team capacity must be considered when planning the
scope of work for the iteration. The capacity is determined by the teams size, availability and velocity, which refers to the speed at which a team can implement and test
use cases and change requests.
As the project progresses, it is often the case that requirements are handled with less effort which results in an increase in the teams velocity. Velocity can be used to
develop the initial estimates of the duration and effort required to complete the current iteration.
A teams velocity over time can be tracked using a burn-down Chart.
The burn-down chart above tracks progress by showing a decrease in the remaining hours. A project team can select any measure they deem relevant to measure
progress such as the number of scenarios completed, days remaining, etc.
The current teams capacity drives the initial estimates for the effort and duration for the given iteration. These initial estimates are needed to select which objectives will
be included in the Iteration Plan and will be further refined as the Iteration Planning progresses.
Deliverables for the Iteration
The deliverables should be associated with one or more of the iterations objectives. The iterations deliverables should not be confused with the OUM task work products.
The work products are just a means to an end to producing the deliverable and are not necessarily related to the projects objectives.
The most important deliverable of any iteration is the increment that will be developed. This is defined in OUM by the set of use cases and other non-functional
requirements that will be achieved during the iteration. These requirements are selected from the projects current MoSCoW list. Selecting the right set of requirements
requires collaboration among all team members and should be focused on the current Ms and Ss shown on the MoSCoW list. Simply stated, the MoSCoW List registers
the known business requirements. Each requirement is classified by the first letter of: Must, Should, Could or Wont.
As the project moves along and risks are retired, the focus of the iterations can shift to filling out the needed functionality for the product under development. Also, change
requests and identified defects can be addressed as the more architecturally significant use cases have been realized. To achieve the right balance the required
functionality, change requests and defects must be prioritized and estimated by analyzing the MoSCoW List. See Task RD.045 - Prioritize Requirements for more
information on how MoSCoW is used in OUM.
The second document in the Iteration Plan is the WBS Project Workplan. It lays out the detailed tasks required to achieve the scope that has been established for the
current iteration. This is done by selecting the appropriate tasks from the OWM work breakdown structure (WBS) for the current phase of the project.
As with any OUM project, it is recommended that the project manager build the Project Workplan by starting with the appropriate pre-tailored view for the type of project
under consideration (Solution-Driven Application Implementation, Requirements-Driven Application Implementation, etc.) and scaling the project for the given
circumstances. The Project Workplan should focus on the tasks included in the OUM Implement Core Workflow, which identifies the core tasks within the Implement
Focus Area.
Resources need to be associated with each OUM task included in the Project Workplan. The resources are assigned based on availability and matching the appropriate
skill-set to the task. All OUM tasks contain a Roles and Responsibilities table that can be used when assigning resources to tasks. In addition, the Project Roles reference
page provides additional information about the specifics of each role.
Once the resource assignments have been made estimates can be developed for each task associated with the iteration. The detailed estimates are determined by
refining the initial capacity-based estimates through the use of traditional estimating techniques that can be augmented through a commitment-driven approach. The
commitment-driven estimating approach involves asking those team members assigned to provide an estimate of how much effort will be required to complete the tasks
for each requirement in the iteration.
The individual task estimates balanced with the team velocity form the basis for the estimates for the Project Workplan. These estimates should be verified against
broader estimates completed as part of the initial planning effort for the iteration.
OUM strives to minimize dependencies within the detailed Project Workplans due to the limited duration of the plans. The key to reducing dependencies is to select
relatively independent bits of functionality that can then be integrated to achieve the iterations objectives. However, dependencies cannot be completely eliminated and
must be taken into account. This is where the project manager must work with the project team and stakeholders to do further analysis of the MoSCoW List. The
dependencies for the use cases addressed in the current iteration must be reflected on the MoSCoW List must also be reflected in the detailed plan for the iteration.
Each objective must be associated with an evaluation criterion that defines how the achievement will be measured and the levels of those measurements that will be
considered a success. These evaluation criteria must be clear and not subjective. The evaluation criteria must be objective and measurable so that progress toward the
projects goals can be demonstrated at the end of the iteration.
Iteration assessments are essential since iterative development is a collaborative endeavor between the project team, end users and project sponsors. The iteration
assessments are important events since they uncover potential issues that could derail the iteration. They also allow the team the ability to take necessary corrective
action to get the project righted. Iteration assessments include demonstrating evidence of results, open and honest review of the iteration, discussion on how to improve
the next one and acceptance reviews to ensure objectives have been met and the evaluation criteria have been satisfied.
Because of the large number of variables in a project and their interdependencies, it is not possible to accurately forecast all the outcomes. For this reason, projects rarely
run exactly as per the plan defined at the outset and require active management to stay on track. Without a realistic, up-to-date plan the project is likely to be out of
control and the project manager will lose credibility.
On a regular basis, analyze the Project Workplan for variances and trends for tasks and resources (for example, incomplete tasks to be sure that none have overdue start
or end dates or zero work remaining). Revise task estimates and task assignments as needed to meet the projects schedule and budget. Changes could include but are
not limited to task re estimating, task rescheduling, resource reassignment, and changes due to change orders. When making changes to the work plan, keep the
baseline intact unless the change is due to a change order. If tasks are added due to change orders, these must be base lined. If there are multiple changes consider
consider re-baselining for a package rather than individual changes.
Keep abreast of the projects schedule and estimate to complete this information is derived from the Project Workplan. It is common practice for project managers to
use a separate Resource Plan to determine the resource actuals and estimates to complete. This Resource Plan and the Project Workplan must correlate. The project
manager must be prepared to provide this information (as accurately as possible) whenever asked.
Following the processes developed in the Work Management Plan during Project Start Up, regularly report project progress based on the Project Workplan this would
include entering financials and project start and end dates in any required project progress reports. The projects estimate to complete given in the project progress report
must map to the Project Workplan and must correlate to all other financial reports.
Following the procedure developed in the Work Management Plan during Project Start Up, ensure that the project team is entering time weekly. This may include time
entry to the clients time entry system if the project is T&M.
Reminder: All team time must be entered into the time and expense system - this may include non-billable time.
If the Time and Expense Tracking system has a work breakdown structure reflecting project milestones, ensure that the time entry corresponds to task status. If actuals
are captured in the Project Workplan, a workplan audit needs to be performed monthly to ensure that system to capture time and expenses and the Workplan are in sync.
If actuals are being entered into the Project Workplan, collect this information weekly and enter the actuals into the Project Workplan. These actuals would also provide
task status.
Review the Project Workplan for unassigned tasks and assign tasks to team members that would be the tasks primary resource. Tasks must be assigned at least one
week in advance of their start date unless the task is a recent add on due to a change order. Assignment of tasks must include advising the assignee of task priority,
dependencies, duration, schedule (start and end dates), estimated work, and review schedule. It is good practice to provide team members with a task information sheet,
which lists their individual tasks at a glance.
Keep the project team abreast of the overall project status. On a regular basis, review the project status with the team. Provide an up-to-date hard copy of the Project
Workplan to project team members at least bi-weekly. Give the project team an at-a-glance schedule at pre-defined times this needs to be no less than 2 weeks at a
glance. This is particularly important for the client so that they can plan their work schedule in advance. As the entire team needs to be working toward the same, most
up-to-date version of the plan, ensure that the most current copy of the Project Workplan is understood and accessible to those who need it.
Following the procedure developed in the Work Management Plan (WM.020) during Project Start Up, capture task status from the team and update the Project Workplan
with the status. Again, the timing and content of task status reporting is defined in the Work Management Plan. Usually, it is performed weekly and the information is
given by the team member to the project manager at the end of the work week. It is a recommended practice that the team member provide task status via a weekly task
status report. The team member can also use the status report to communicate risks, issues, and upcoming plans. Review all requests by team members indicating that
a task needs to be re estimated and/or rescheduled. Either approve requests or adjust them. Advise team members as soon as possible of any adjustments made.
The project manager must review and approve all re-estimating and rescheduling; the project managers review could result in the project manager overriding the new
estimate/revised schedule given by a team member. Feedback regarding this approval and the resulting schedule change, if any, needs to be given as soon as possible
to the team member preferably by the first day of the following work week after the status was given. The rule of thumb is that no task should have a zero estimate to
complete if the task is not completed and no task would have overdue start and end dates.
Determining task status should generally be based on the amount of work (hours) remaining. For example, if a task has a 40 hour baseline, 20 hours have been spent on
the task to date and the team member feels that the task can still be completed with the remaining time allocated, the task would be considered 50% complete. However,
if the team member estimates that either more or fewer remaining hours are needed, the task must then be re-estimated. If the team member estimates that the duration
(start and end dates) does not line up to the original duration, the task must be rescheduled (and re-estimated if appropriate).
The team member must work to plan any activities outside of plan need to be reported weekly by the team member and tracked by the project manager. Team
members need to obtain the project managers approval before taking part in unplanned activities. If this is not possible, the team member needs to advise the project
manager of the activity as soon as feasible. The amount of work on these activities needs to be tracked and reported separately from planned work. A recommended
practice is to include an area in weekly team status reports for the team to advise of the unplanned activity performed and the amount of work (hours) performed. The
project manager would log the unplanned activity in a specified area in the work plan including the resource that performed it and the amount of time spent.
Following the procedure developed in the Work Management Plan (WM.020) during Project Start Up, capture all unplanned activities and log them including the activity,
resource, and amount of time spent. A good practice is to include a section in the Project Workplan to log these. They would be closed immediately after being logged.
Include this information when reporting status.
Estimate remaining work on the project by reviewing the Actuals; and by estimating the remaining effort. It is important that the remaining effort is not calculated by Budget
minus Actual. Remaining effort in the project must be calculated.
Other Considerations
The Baseline Project Workplan (WM.010) and Work Management Plan (WM.020) are developed during the Project Start Up phase and set forth the plan, strategy,
policies and procedures for managing work. They should be communicated to the project team in the Work Management Presentation made during the Team Orientation
Meeting. Refer to the Conduct Team Orientation task (STM.050) for more information on the Team Orientation Meeting. During the Team Orientation Meeting and
whenever a new resource joins the project, it is important for the project manager to establish the culture and ground rules for how the project works. The project
manager must ensure that the team members doing the work, clearly understand
the project objectives
the tasks they are accountable for and how they fit into the overall project plan
when they need to be completed by
to what standards or quality criteria
how they are reviewed and approved
the need for timely, realistic reporting and no surprises
The above need to be reinforced throughout the duration of the project.
Project Workplan Backup and Archiving
Along with other key project documents the Project Workplan must be backed-up to secure storage (not on the project managers notebook/PC ) on a weekly basis and
previous versions archived
Engaging Staff
Once a need for a specific resource has been identified, the delays to their being available to the project can be significant, particularly for international resources. A good
Project Workplan will greatly assist identifying resource requirements in advance.
Back to Top
SUPPLEMENTAL GUIDANCE
Iterative and Incremental Project Planning
This task has supplemental guidance for iterative and incremental project planning. Use Planning a Project using OUM - An Iterative and Incremental Approach to access
the supplemental information.
Tailoring OUM for Your Project
Refer to Tailoring OUM for Your Project for an overview of the tailoring process in OUM.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Workplan (WM.010) Start with the Baseline Project Workplan.
Work Management Plan
(WM.020)
The Work Management Plan documents the policies, procedures and processes for managing the Project Workplan during the
project.
Orientation Guide (STM.040)
Oriented Team (STM.050) Oriented Team members (resources) are assigned to tasks in the Project Workplan.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Determining the Number of Iterations Use this technique to refine the estimate of the number of iterations for each phase as the project progresses.
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Work Management.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
Iteration Plan Summary MS WORD - Start with a copy of the initial Iteration Plan Summary (from the Baseline Project
Workplan - WM.010) or the prior Iteration Plan Summary (depending on where you are in the project)
to create the Iteration Plan Summary portion of the Iteration Plan that documents the scope,
objectives and approach for the iteration. Bring forward any work not completed from the prior
iteration and any approved change requests.
WM030_ASSIGNMENT_REQUEST.DOC MS WORD
WM030_WORK_PRODUCT_TRACKING_SPREADSHEET.DOC MS WORD
WM030_UNPLANNED_ACTIVITY_LOG.DOC MS WORD
WM030_ITERATION_END_REPORT.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
WM.040 - TRACK SCHEDULE PERFORMANCE
Tracking scheduled performance is periodically measuring actual project accomplishments against what was planned. This important output of this process is the
determination of whether the plan is on track or if a meaningful variation from the plan has occurred.
Technically speaking, the dividing line between a meaningful variation and a variation that is not significant is called the Variance Threshold. Project managers should
always choose a variance threshold for the schedule early on (often a 10% variance is used) so that they have a standard to compare against.
ACTIVITY
PEC.ACT.MPW Manage Project Workplan
Back to Top
WORK PRODUCT
Schedule Performance
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Calculate schedule variance and schedule performance index. Schedule Variance (SV) and Schedule Performance Index (SPI)
2 Forecast the project completion date. Completion Date Forecast
Back to Top
APPROACH
Track the Schedule Performance
One technique used to track the schedule performance is by employing the Earned Value Technique:
Calculate the Schedule Variance (SV) and Schedule Performance Index (SPI)
The two earned value components used to calculate schedule variance (SV) and the schedule performance index (SPI) are Planned Value and Earned Value. Used
together, they can give you an objective measurement of the project's status and provide a foundation for building a reliable forecast. The project manager should assess
the status of the schedule at least every month - preferably weekly.
Calculate Planned Value (PV) for the Project at the End of the Current Reporting Period
Planned Value is defined as the budgeted cost of the work scheduled up to the end of the current period. This information is typically available directly from your
scheduling tool, but only if the workplan is resource-leveled and cost burdened. In Microsoft Project, for example, the data is available in the Earned Value view.
Calculate Earned Value (EV) for the Project at the End of the Current Reporting Period
Earned Value is the budgeted cost of the work actually completed at the end of the current reporting period. This information may also be available from your scheduling
tool as mentioned above.
Calculate the Schedule Variance and Schedule Performance Index (SPI)
Schedule Variance = Earned Value - Planned Value SPI = Earned Value/Planned Value
Tip: One confusing aspect of earned value analysis is that Schedule Variance is a monetary amount. This makes it difficult to convey to anyone outside the project
management community since they do not intuitively grasp the relationship between time and cost. To eliminate the potential misunderstanding, convert SV to days by
using the average cost per workday.
Tip: To convert the SPI to an easily understandable percentage, multiply it by 100, then subtract it from 100. For example, an SPI of 1.03 becomes 103, then 3 percent. A
positive result means you are ahead of schedule, a negative result means you are behind schedule.Evaluate upcoming project work, risks and potential corrective
actions. Are there events or risks on the horizon that are likely to have a significant adverse or positive impact on cost performance? Are there corrective or preventive
actions that the team, our management or client management can realistically take to improve the situation?
Forecast the Project Completion Date
Determine the best method to forecast the completion date. Assess underlying schedule performance drivers and trends. For example, determine whether every task is
taking longer than planned or if there have been a few, significant exceptions. If a lot of tasks are running over, look for a global problem. You should validate the original
assumptions, estimate, and Validate Scope definition. If there are relatively few tasks running into problems, they should point you to the source of the problem (i.e.,
under-performers on the team, poor leadership, availability problems). Improving schedule variances may indicate a learning curve being surmounted and/or the
momentum of effective team building. Worsening schedule variances may indicate significant problems with the original estimates, staff problems, poor project
management or other major challenges. Based on this assessment of the situation, the project manager must select the most appropriate technique for forecasting the
project's completion date. The three approaches are:
Critical Path Method (CPM)
This method is the standard approach used by most project managers to produce a a single point-in-time estimate for project
completion. This is the default for all Microsoft Project plans.
Performance Evaluation and Review
Technique (PERT)
Some project managers prefer to use PERT, even though it requires more data, because they feel that it produces a more reliable
completion date. PERT estimation requires that you enter optimistic and pessimistic estimates in addition to the most probable
duration for each task. PERT then computes a completion date relying on the assumption that tasks are more likely to finish late
than finish early. The project end date computed by PERT will be later than the same project analyzed using CPM, and is likely to
be closer to the actual completion than CPM. In fact, PERT can be very accurate when non-critical paths have a fair amount of
slack. The formula for PERT is:
(Optimistic Estimate + (4 times Most Likely Estimate) + Pessimistic Estimate) divided by/6
Monte Carlo Simulation
The only tool capable of correctly analyzing for convergence issues is one that uses Monte Carlo simulation. Monte Carlo
simulation involves examining a large sample of possible outcomes for each task and path. The tool builds a statistical picture of
the likelihood of the project finishing by specific dates. The same amount of information is required as for a PERT analysis, but
the result is a much more complete picture of your project. Monte Carlo simulation can tell you:
What is the probability of your project finishing on a specific date?
What is the probability that your project will stay under budget?
What completion date corresponds to a confidence level (for example 95%) that you need
Monte Carlo simulation can be done in Excel and there are popular Monte Carlo simulation tools available outside of Oracle.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Calculate performance metrics and measure against variance threshold. Recommend or take corrective action to resolve
meaningful deviations from plan.
85
Client Project Sponsor Approve corrective actions recommended by the project manager. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Baseline Project Workplan
(WM.010)
The Baseline Project Workplan provides the baseline for tracking performance.
Work Management Plan (WM.020) The Work Management Plan documents the policies, procedures and processes for managing the Project Workplan during the
project.
Project Workplan (WM.030) At any given point, the current Project Workplan is used to track performance against planned performance.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Metrics for Agile Projects Use this technique to measure actual project accomplishments against what was planned for agile projects.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
WM.050 - MANAGE APPROVALS
As part of the Work Management process, approvals must be managed. In this task, you manage the approval of project work products based on the procedures defined
in the Work Product Approval Process component of the Work Management Plan. This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MSAA Manage Scope, Acceptance and Approvals
Back to Top
WORK PRODUCT
Managed Approvals - Managed Approvals is the executing the procedures defined in the Work Product Approval Process of the Work Management Plan. As project
work products requiring approvals are completed, the approvals are initiated per the Work Product Approval Process.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Obtain approval for identified project work products as
they are completed.
Approval
Certificate
Complete the Approval Certificate for the work product and send to defined approver
as defined in the Work Product Approval Process.
2 Follow-up that the Approval Certificate has been received
within the determined timeframe.

3 If the Approval Certificate has not been received, initiate
the Escalation procedure.
Initiate the Escalation procedure defined in the Work Product Approval Process.
4 File Approval Certificates. Signed Approval
Certificates

Back to Top
APPROACH
Use the Work Product Approval Process component of the Work Management Plan to implement this task. As project work products are completed, complete Approval
Certificates and forward to the designated approver for a signature. Follow-up that Approval Certificates are received in accordance with the timeline provided in the Work
Product Approval Process. If not, initiate the defined Escalation procedure. File signed Approval Certificates.
Managing work product approvals is an important task. If they are not managed, the project timelines can be impacted by schedule slippage and rework or even
cancellation. There is more to the process than simply walking a document over to the sponsor for a signature.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Work Management Plan (WM.020) The Work Management Plan documents the Work Product Approval Process for managing approvals during the project.
Project Workplan (WM.030)
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
WM.060 - CLOSE WORK MANAGEMENT
During the Project Closure phase, the project manager is responsible for closing out project team work activities and the Project Workplan, archiving the project's work
products and work products, and providing final project metrics.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Work Management
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Close the Project Workplan and analyze
metrics.
Completed Workplan, Schedule Metrics
Report
Perform the necessary functions to close the Project Workplan and
produce the Schedule Metrics Report.
2 Document any lessons learned. Work Management Lessons Learned This report is used to create the Lessons Learned report produced in the
Communication process.
3 Close Work Management and Project
Workplan execution.
Closed Time Entry System of Record,
Archived Work Products

Back to Top
APPROACH
Close Project Workplan
Based on the project teams final status, update the Project Workplan with the final status from the team and mark all tasks complete.
Perform the final reconciliation between the Project Workplan and the time reporting system of record.
Perform a final analysis of the Project Workplan for variances and trends.
Produce the final Schedule Metrics Report and provide to internal and client management.
Perform the final back up and archive of the Project Workplan.
Close Work Management and Project Workplan Execution
Close project team time entry in the time entry system of record.
Create archive folders for hard copy work information. Create a separate folder for each activity.
Create archive media for soft copy work products, organized in folders by activity level.
Gather lessons learned during the Project Workplans execution and enter them into the lessons learned repository.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Gather work products and create archives for each activity. 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
WM060_WORK_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[RKM] RISK MANAGEMENT
Risk Management is a structured process for identifying, documenting, gaining agreement on, and communicating risks throughout the lifecycle of a project. This process
does not deal with the management of issues and problems. There are dealt with in the Issue and Problem Management process. Risks are differentiated from issue and
problems as follows:
An Issue is an open concern or matter that is under discussion and could adversely impact the success of a project.
A Problem is a perceived variance between the expected and actual ability of an item to fulfill its defined purpose (for example, a software bug, consistent
unexpected downtimes, a faulty design, service request, etc.)
Risk is the possibility of an uncertain future outcome or condition, that if it occurs, has a positive or negative effect on a projects objectives, which may be mitigated
by pre-emptive action.
A Risk is viewed in two dimensions:
Risk Probability - the likelihood that a certain risk will negatively affect a project
Risk Impact - measures the anticipated severity of a risk
Although risks can have a positive outcome, when we talk about risk on an Oracle project, were usually concerned with things that may adversely affect the project. Think
about risks in relation to their effect on the triple constraints (scope, schedule and cost) and solution quality. Examples of common risk sources on our projects include:
Size and complexity of effort (for example, solution footprint, number of business units, geographic breadth)
Technical (infrastructure technology, applications, third party, legacy)
Staffing (both client and Oracle)
Funding
Timeline
Culture (national and organizational)
Management style
Clarity of purpose
Business value
Client relations
Organizational change management
Project organization structure
External factors
The goal of Risk Management is to reduce or eliminate predictable variances in the projects schedule and budget. Risk Management does not necessarily eliminate risk,
but attempts to reduce the exposure to risk.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During Project Start Up, the project manager is responsible for documenting, gaining agreement on, and communicating a structured Risk Management Plan as well as
developing a Risk Management System for identifying, documenting and mitigating project risks throughout the lifecycle of the project.
A structured Risk Management Plan includes the following components:
Risk identification
Risk analysis and prioritization
Risk response planning
Risk monitoring and control
A formal Risk Management System is also created for tracking risks.
A formal risk assessment is required at bid time. During Project Start Up, it needs to be revisited and a Baseline Risk Assessment should be created.
Project Execution and Control Phase
Risk management becomes even more critical during Project Execution and Control. It is important for the project manager to regularly conduct risk assessments.
Particular attention should be paid to risks prior to production cutover.
Project Closure Phase
During the Project Closure phase, there may still be risks that will impact the client as they move forward into production (e.g., support risks, operational risks, etc.). The
project manager should conduct a Post-Production Risk Assessment and evaluate these risks and communicate them to the client.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS RKM.010 Develop Risk Management Plan Risk Management Plan Y Core
PS RKM.020 Conduct Baseline Risk Assessment Baseline Risk Assessment Y Core
PS RKM.030 Develop Risk Management System Risk Management System Core
Project Execution and Control
PEC RKM.040 Manage Risk Managed Risk Core
PEC RKM.050 Monitor and Control Risk Assessed Risk Y Core
Project Closure
PC RKM.060 Conduct Post-Production Risk Assessment Post-Production Risk Assessment Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager

Client (User)
CPS Client
Project
Sponsor

Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
RKM.010 - DEVELOP RISK MANAGEMENT PLAN
The goal of this task is to identify possible risk, calculate their potential impact on the project, and develop options for handling each risk should it develop during the
course of the project as well as develop the process (procedure) for managing risk during the Execution and Control phase of the project. This information is then
documented in the Risk Management Plan. The Risk Management Plan is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Risk Management Plan - The Risk Management Plan documents possible risk and their potential impact on the project (e.g., low, moderate or high) and the options for
handling each risk should it develop during the course of the project as well as the process (procedure) for managing risk during the Execution and Control phase of the
project. The Risk Management Plan is a key component of the Project Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Determine which risks are likely to affect the project. Identified Risks Watch
List
Document the characteristics of each identified risk.
2 Identify the priority of the risk response for each identified
risk.
Qualitative Risk
Response
Document the priority of the risk response for each identified risk and use it as
an input to quantifying each risk.
3 Quantify each identified risk. Projected Possible Risk
Impacts
Document the possible impacts for each identified risk on project
implementation.
4 Determine a mitigating response to each identified risk. Risk Response Plan Document a response plan for each identified risk.
5 Develop the Risk Management Process. Risk Management
Process
Document the procedure for managing and tracking risk during Project
Execution and Control.
6 Define roles and responsibilities. Roles and
Responsibilities
List any and all roles involved and describe the responsibilities.
7 Obtain key stakeholder agreement and approval on the
Risk Management Plan.
Approved Risk
Management Plan
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
The project manager (and sometimes the client project manager) is responsible for managing risk overall. In a large project, there may be a full-time position dedicated to
managing risk.
Risk management is "an organized means of identifying and measuring risk and developing, selecting, and managing options for handling these risks." The Risk
Management Plan specifically addresses the following:
Identified Risks Watch List - Determine which risks are most likely to affect the project and document the characteristics of each including trigger events. The
trigger event can be used to monitor for the risk.
Qualitative Risk Response - Identify the priority of the risk response and then use it as an input to quantify the risk (i.e., projecting possible risk impacts).
Projected Possible Risk Impacts - Quantify the risk. Analyze and evaluate each risk and risk interaction to assess the range of possible impacts on the project
implementation.
Risk Response Plan - Determine the response to a risk event by examining the range of possible responses and choosing the best approach.
Risk Management Process - Develop the procedures for managing risk during Project Execution and Control. This process should include monitoring already
identified potential risks and the process for dealing with them if their trigger event occurs as well as dealing with entirely newly identified risks. The process should
include components for identifying, assessing, approving, handling, tracking and reporting risk.
Roles and Responsibilities - Identify and document, by roles and responsibilities, the person who owns and manages the Risk Management Plan -- the person who
proactively looks for any real or potential problems. If someone other than the project manager is responsible for risk management, the project manager should
meet with them regularly to discuss their risk areas. Document those conversations, too. When all is said and done, the project manager is ultimately responsible.
The table below lists some possible responses to risk.
Response Description
Avoid
Eliminate the cause of the risk. Now that you know about this particular risk, you plan to steer around it altogether.
Transfer
Deflect the risk by transferring the risk outside the organization. Possible candidates include a subcontractor, the customer, or a supplier. Transfer often
involves developing contract terms and conditions unique to the situation.
Mitigate
Deal with the risk in one of these standardized approaches:
Reduce the probability of occurrence, frequently by choosing an alternate approach.
Reduce the impact of the risk event by having a plan in place to immediately react to the event if it occurs. That might mean flying in an expert to
help move the project along if the team runs into a problem they cant solve.
Accept and
Control
Accept some of the risks from the offset and control those throughout the lifecycle.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Risk Management requirements that should be taken into consideration
when developing the detailed Risk Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RKM010_RISK_MANAGEMENT_PLAN.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
RKM.020 - CONDUCT BASELINE RISK ASSESSMENT
During Project Start Up, conduct an baseline risk assessment. The objective is to identify risk, assess current risk levels and ensure proper risk techniques are applied.
This assessment is conducted by:
project sponsors
project leadership team
project team members
other stakeholders from the team (for example, internal risk managers)
ACTIVITY
PS.ACT.RBC Review Bid and Contract
TASK GROUPS
Back to Top
WORK PRODUCT
Baseline Risk Assessment - The Baseline Risk Assessment provides a point-in-time snapshot of the risk at Project Start Up.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify any current potential risk issues. Identified Risks Document the characteristics of each identified risk.
2 Identify the priority of the risk response for each
identified risk.
Qualitative Risk
Response
Document the priority of the risk response for each identified risk and use it as an
input to quantifying each risk.
3 Quantify each identified risk. Projected Possible
Risk Impacts
Document the possible impacts for each identified risk on project implementation.
4 Determine a mitigating response to each identified risk. Risk Response Plan Document each mitigating response to each identified risk.
5 Obtain key stakeholder agreement and approval on the
Risk Response Plan.
Approved Risk
Response
For each actual risk identified, obtain any necessary sign-off or Approval
Certificate for the determine response.
6 Execute the approved response for each risk. Mitigated Risk Document the results of applying the response to each risk.
Back to Top
APPROACH
Conduct a Baseline Risk Assessment for the project in the Project Start Up phase. The Baseline Risk Assessment includes the following components:
Identified Risks - Determine any risks that are currently affecting the project and document the characteristics of each. Qualitative Risk Response - Identify the
priority of the risk response and then use it as an input to quantify the risk (i.e., projecting possible risk impacts). Projected Possible Risk Impacts - Quantify the
risk. Analyze and evaluate each risk and risk interaction to assess the range of possible impacts on the project implementation. Risk Response Plan - Determine
the response to a risk event by examining the range of possible responses and choosing the best approach. Approved Risk Response - If necessary, obtain key
stakeholder agreement for the response.
Mitigated Risk - Determine if the the response to a risk event has mitigated the risk and document the results.
Use the Baseline Risk Assessment as a tool to monitor risk during the project.The following techniques for identifying risk are recommended:
Collect project historical data by interviewing stakeholders. Draw on past experience.
Use expert judgment.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Risk Management Review (Bid Review Process)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RKM020_BASELINE_RISK_ASSESSMENT.DOC MS WORD
RKM020_RISK_MITIGATION.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
RKM.030 - DEVELOP RISK MANAGEMENT SYSTEM
In this task, you develop the system to support and execute the Risk Management Process documented in the Risk Management Plan. The Risk Management Process
contains the procedures for managing risk during Project Execution and Control. This includes identifying, assessing, approving, handling, tracking and reporting risk.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Risk Management System - The Risk Management System incorporates the various pieces required for managing risk during the project. It includes the following
components:
Risk Form
Risk Log
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Create or obtain a risk form. Risk Form This form is used to capture individual risk items as they are identified.
2 Create or obtain a risk log. Risk Log This log is used to track all identified risk issues.
Back to Top
APPROACH
The actual procedures for the Risk Management System are defined in the Risk Management Process component of the Risk Management Plan. The focus here is to
support and execute those procedures. Generally, this involves obtaining or creating a Risk Form and a Risk Log. When obtaining or creating your forms keep in mind, at
a minimum, the following information should be captured:
Risk ID Each risk should have a unique ID.
Submitted By Enter the name of the person and/or organization who raised the risk.
Date Submitted Enter the date the risk was recorded in the Risk Log.
Estimated Response Plan Date Enter the date that a mitigation plan for the risk is expected to be in place.
Consequences Complete the impact to the project and/or business in terms of money, time, and/or quality.
Application/Flow/Module If applicable, enter the name of the application, flow, or module to which the risk pertains.
Type Enter the type of risk (e.g., technical, process, organizational, etc.).
Title Provide a short description of the risk (usually a few words or a sentence, helpful when reporting risks).
Description Enter a complete description of the risk, the more details the better.
Probability Indicate the probability of the risk.
Escalation Indicate the current escalation level and anticipated date and level of next escalation.
Target Date Enter the target date for closure review of this risk.
Assigned To Enter who currently owns mitigation of the risk.
Status Enter the current status of the risk (typical values are open or closed).
Risk Response Plan Provide a detailed description of actions (including dates and owners) required to deal with the risk.
The Risk Form is used to raise a risk item and provide the basic information to start the process. The Risk Log is used to track the progress and provide reporting.
Consider a central risks repository for delegated project team members to log and update risks as required. The project manager should avoid the scenario where many
team members are updating the risk logs.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Risk Management Plan (RKM.010) Use the processes defined in the Risk Management Plan to develop the Risk Management System.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Risk Portfolio Use this technique to assess overall project risk.
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Risk Management.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RKM030_RISK_FORM.DOC MS WORD
RKM030_RISK_LOG.XLS MS EXCEL
RISK_ISSUE_PROBLEM_LOG.XLS MS EXCEL - This template provides a combined Risk, Issue and Problem Log.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
RKM.040 - MANAGE RISK
The Manage Risk task entails executing the process detailed in the Risk Management Plan for the potential risks identified in the Identified Risks Watch List. While there
is a value in working through the process of developing the plan, there is a lot more value in working with the plan regularly to help navigate the implementation. Resist
the temptation to carefully file the plan away somewhere. This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MRIP Manage Risks, Issues and Problems
Back to Top
WORK PRODUCT
Managed Risk - Managed Risk is executing the procedures defined in the Risk Management Plan when an already identified potential risk from the Identified Risks
Watch List is triggered. Risks are are monitored and if detected their Risk Response Plan is executed to mitigate the risk.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Monitor risk. Updated
Project
Management
Plan
Monitor the risks already identified in the Identified Risks Watch List.
Update the appropriate components of the Project Management Plan
for any new potential risks.
2 As actual risks are identified (e.g., their trigger event occurs), route them
through the procedures identified in the Risk Management Process of the
Risk Management Plan.
Risk Form Once an actual risk is triggered, complete a Risk Form.
3 Add each identified risk (completed Risk Form) to the Risk Log and track
its progress.
Risk Log Track all risks from identification to mitigation.
4 Respond to risks. Implemented
Risk
Response
Plan
Implement the agreed upon Risk Response Plan from the Risk
Management Plan when symptoms/risks occur.
5 Track and report individual risk status. Risk Log Update the Risk Log.
Back to Top
APPROACH
Monitor Risk - Monitor any risks already identified on the Identified Risks Watch List developed in the Risk Management Plan. Make risk review an agenda item for the
project meetings to keep risk awareness in front of the entire project team. If any new potential risks are identified, analyze the probability and severity of each risk and
update all the appropriate components of the Risk Management Plan.
Respond to Risk - When a trigger event occurs, execute the response steps from the Risk Management Plan. Reiterate the importance of project team members
identifying concerns about new risks as they become aware of them. Remind them that it is better to raise a concern and decide not to take any action based on the
information than to miss a trigger event altogether.
Use the Project Workplan - Add tasks to the Project Workplan for risk reviews following major milestones and/or at the end of each phase (e.g., after competing the
Construction phase). This provides both lessons learned on the phase that is closing out and provides an opportunity to review issues associated with the upcoming
phase. Reassessing the upcoming phase is important because you will know more than you did at the beginning of the project. That information will help you reassess
risks you identified initially as well as spot new risk.
Tool Tip: Use Microsoft Projects Task Notes capability to insert risk trigger information into your Project Workplan. This will make it easier for the team to keep an eye on
specific areas or exposures.
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Risk Management Plan (RKM.010)
Risk Management System (RKM.030)
These work products document the processes and system for managing risks during the project.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
Use Risk Form created/edited in RKM030
Use Risk Log created/edited in RKM030
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
RKM.050 - MONITOR AND CONTROL RISK
The Monitor and Control Risk task entails executing the procedures detailed in the Risk Management Process for unplanned or NEW risks that were not already identified
in the Identified Risks Watch List. These risks do not already have the benefit of being analyzed and having a Risk Response Plan in place in the Risk Management Plan.
Therefore, the risk analysis, response planning and approval are also part of this task. This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MRIP Manage Risks, Issues and Problems
Back to Top
WORK PRODUCT
Assessed Risk - Assessed Risk is the executing the procedures defined in the Risk Management Plan for NEWLY identified risks that have not already been identified as
potential risks in the Risk Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Conduct regular risk assessment and identify any current
risks.
Risk Form
For each risk identified, complete the Risk Form. Include the following:
characteristics of the identified risk
priority
project impacts
risk response recommendation
Follow the procedures set forth in the Risk Management Plan.
2 Add each newly identified risk (completed Risk Form) to the
Risk Log to track its progress.
Risk Log Track all risks from identification to mitigation.
3 Obtain key stakeholder agreement and approval on the risk
response recommendation.
Approved Risk
Response
For each risk, obtain any necessary sign-off on the Risk Form or Approval
Certificate for the recommended response.
4 Execute the approved response for each risk. Mitigated Risk Document the results of applying the response to each risk.
5 Track and report results of risk assessment. Risk Log Update the Risk Log.
Back to Top
APPROACH
During Project Execution and Control, monitor periodically for unplanned for risk. If any new unplanned for risks are encountered, analyze and asses the risk and
complete a Risk Form with the following information:
Description
Priority
Projected Impacts
Risk Response Recommendation
Use the Risk Log to monitor and track risk.
Periodically ensure the following:
Reassess that the project assumptions are still valid.
Make sure the policies defined in the Risk Management Plan are being followed. Modify contingency or reserve funds to keep in line with the risks of the project.
Update the Risk Management Plan, as necessary.
An easy way to remember the difference between monitoring and controlling risk is with a simple mnemonic. Project delays and associated costs caused by snowstorms
in Canada come out of contingency funds. Project delays and associated costs caused by snowstorms in Mexico come out of management reserve.
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Risk Management Plan (RKM.010)
Risk Management System (RKM.030)
These work products document the processes and system for monitoring and controlling risks during the project.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
Use Risk Form created/edited in RKM030
Use Risk Log created/edited in RKM030
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
RKM.060 - CONDUCT POST-PRODUCTION RISK ASSESSMENT
During Project Closure, conduct a post-production risk assessment to properly ascertain any remaining or possible risk prior to transitioning the Risk Management System
to the client.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Post-Production Risk Assessment - The Post-Production Risk Assessment provides a point-in-time snapshot of the risk at Project Closure.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify any current potential risk issues. Identified Risks Document the characteristics of each identified risk.
2 Identify the priority of the risk response for each
identified risk.
Qualitative Risk Response Document the priority of the risk response for each identified risk and use it as an
input to quantifying each risk.
3 Quantify each identified risk. Projected Possible Risk
Impacts
Document the possible impacts for each identified risk on project implementation.
4 Determine a mitigating response to each
identified risk.
Risk Response Plan Document each mitigating response to each identified risk.
5 Compile the assessment into one document. Post-Production Risk
Assessment
Compile all the components into one document.
6 Document any lessons learned. Risk Management Lessons
Learned
This report is used to create the Lessons Learned report produced in the
Communication process.
Back to Top
APPROACH
Conduct a Post-Production Risk Assessment for the project in the Project Closure phase. The Post-Production Risk Assessment includes the following components:
Identified Risks - Determine any risks that are currently affecting the project and document the characteristics of each.
Qualitative Risk Response - Identify the priority of the risk response and then use it as an input to quantify the risk (i.e., projecting possible risk impacts).
Projected Possible Risk Impacts - Quantify the risk. Analyze and evaluate each risk and risk interaction to assess the range of possible impacts on the project
implementation.
Risk Response Plan - Determine the response to a risk event by examining the range of possible responses and choosing the best approach.
Transition the Risk Management System to the client and provide to them the Post-Production Risk Assessment. The information in the Assessment provides the client
with a plan for future Risk Management to reduce exposure and ensure a proper response to certain project risks.
Lastly, document any lessons learned for inclusion in the Lessons Learned reporting produced in the Communication process.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or 15
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
RKM060_POST_PRODUCTION_RISK_ASSESSEMENT.DOC MS WORD
RKM060_RISK_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[IPM] ISSUE AND PROBLEM MANAGEMENT
Issue and Problem Management is a structured process for identifying, documenting, tracking and resolving issues and problems as they occur throughout the lifecycle of
a project. The project manager is responsible for defining, gaining agreement on, and communicating, a structured process to capture and track issues and problems
using a formal issue/problem log. This log must be actively maintained, and effort must be devoted to put closure on critical project issues. It is the project managers
responsibility to record, assign, and track issues as well as to drive the resolution of open issues/problems. The project must also communicate and report on
issue/problem status.
While issues and problems are very different, the management of them is very similar. Issues are differentiated from problems and risks as follows:
An Issue is a point or matter that is not settled and is under discussion (there may also be opposing views and/or disagreements). Some issues if not addressed,
could adversely impact the success of a project. (From PMI PMBOK Third Edition)
A Problem is a perceived variance between the expected and observed ability of an item to fulfill its defined purpose (for example, a software bug, consistent
unexpected downtimes, a faulty design, TARs/SRs, etc.). (From PMI PMBOK 2000)
A Risk is an uncertain event or condition, that if it occurs, has a positive or negative effect on a projects objectives. (From PMI PMBOK Third Edition)
Issues and problems can be raised by any project stakeholder, including project team members, the client, third-party integrators, or vendors. They should be categorized
by type and priority, and an estimated closure date should be assigned. Once the issue/problem has been formally documented, it is typically assigned to an owner for
resolving. If an issue/problem cannot be resolved, it must be escalated to senior management for resolution. The resolution may result in the need for a project change
requiring a change order. The investigation and/or resolution may require the establishment of one or more entries in the risk log for assessment and quantification.
Note: Issues related to product expectations, including TARs/SRs, should be recorded as problems, not issues.
Key aspects of Issue and Problem Management are:
Enforce issues/problem resolution
Analyze cause and effects associated with issues/problems
Capture, analyze, and resolve and/or escalate issues/problems
Establish reporting metrics (for example, by category, by application, by flow, etc.)
A best practice is to discuss open issues and problems in project status meetings, including executive steering committee meetings, and to make an effort to put a hard
closure on lingering issues/problems.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During Start Up, establish both the Issue Management Strategy and the Problem Management Strategy as well as the Issue and Problem Management System
Project Execution and Control Phase
Following the strategy, processes, and procedures established during Project Start Up, the project manager must make sure that all project issues are carefully and
accurately logged, prioritized, and assigned for closure. Moreover, it is the project managers responsibility to drive open issues to a closure that fulfills the contractual
requirements in a manner that is acceptable to the client.
Project Closure Phase
During Project Closure, the project manager must generate a final issue and problem report and communicate any remaining open issues and problems to the client.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS IPM.010 Develop Issue Management Strategy Issue Management Strategy Y Core
PS IPM.020 Develop Problem Management Strategy Problem Management Strategy Core
PS IPM.030 Develop Issue and Problem Management System Issue and Problem Management System Core
Project Execution and Control
PEC IPM.040 Manage Issues and Problems Managed Issues and Problems Y Core
Project Closure
PC IPM.050 Produce Final Issue and Problem Report and Close Log(s) Closed Issue and Problem Log Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager

Client (User)
CPS Client
Project
Sponsor

Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IPM.010 - DEVELOP ISSUE MANAGEMENT STRATEGY
Develop the definition, purpose and overall project strategy for handling issues. In addition, develop the process (procedure) for managing issues during the Execution
and Control phase of the project. Document this information in the Issue Management Strategy. The Issue Management Strategy is a key component of the Project
Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Issue Management Strategy - The Issue Management Strategy contains the definition, purpose and strategy for issue management as well as the process (procedure)
for managing issues during the Execution and Control phase of the project. The Issue Management Strategy is a key component of the Project Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Define issues. Definition Provide a clear definition of what constitutes an issue.
2 Define the purpose of issue management. Purpose Document the purpose.
3 Define the overall project strategy for issue management. Strategy Document the strategy.
4 Develop the Issue Management Process. Issue Management Process Document the procedure for managing and tracking issues during
Project Execution and Control.
5 Define roles and responsibilities. Roles and Responsibilities List any and all roles involved and describe the responsibilities.
6 Obtain key stakeholder agreement and approval on the Issue
Management Strategy.
Approved Issue
Management Strategy
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Because issues and problems have similar management needs, they have been combined into a single Issue and Management process. For the benefit of project team
members, be sure to provide a very clear and specific definition of what constitutes an issue. The first decision you may need to make for issues and problems is whether
or not to combine the management of issues and problems. Some reasons to consider whether or not to combine issue and problem management follow:
Can you create or obtain a single form and log that meets the needs of both issues and problems?
What is the size of your project? For a small project, you may want to combine issue and problem management, while you may want to separate them for larger
projects.
Follow a common standard strategy throughout the project. This strategy should remain the same from Project Start Up until Project Closure.
Develop the procedures for managing issues during Project Execution and Control. Issues should be logged and tracked at the offset of the project so as not to cause any
project schedule delays. The Issue Form and Issue Log are common tools used by project managers to log, prioritize and assign issues to the project team. Most projects
have issues, agreeing on closing issues is the responsibility of the project manager. The Issue Management Process should include the following:
Use of an Issue Form
Prioritize issues, including establishing clear guidelines and definitions for discrete issue priorities (e.g., showstopper/executive, high, medium, low, etc.).
Assign each issue to a person(s) responsible for owning resolution and for performing impact analysis, as required.
Use of an Issue Log
Track and report issues status (e.g., issue aging, open/closed status, resolution status, etc.).
Escalation Procedures, including how long does the issue stay at one level before it is escalated to the next level up to the executive committee.
Document any roles involved and describe the responsibilities.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Issue Management requirements that should be taken into consideration
when developing the Issue Management Strategy.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IPM010_ISSUE_MANAGEMENT_STRATEGY.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IPM.020 - DEVELOP PROBLEM MANAGEMENT STRATEGY
Develop the definition, purpose and overall project strategy for handling problems. In addition, develop the process (procedure) for managing problems during the
Execution and Control phase of the project. Document this information in the Problem Management Strategy. The Problem Management Strategy is a key component of
the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Problem Management Strategy - The Problem Management Strategy contains the definition, purpose and strategy for problem management as well as the process
(procedure) for managing problem during the Execution and Control phase of the project. The Problem Management Strategy is a key component of the Project
Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Define problems. Definition Provide a clear definition of what constitutes a problem.
2 Define the purpose of problem management. Purpose Document the purpose.
3 Define the overall project strategy for problem management. Strategy Document the strategy.
4 Develop the Problem Management Process. Problem Management
Process
Document the procedure for managing and tracking problems during
Project Execution and Control.
5 Define roles and responsibilities. Roles and Responsibilities List any and all roles involved and describe the responsibilities.
6 Obtain key stakeholder agreement and approval on the
Problem Management Strategy.
Approved Problem
Management Strategy
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Because issues and problems have similar management needs, they have been combined into a single Issue and Management process. For the benefit of project team
members, be sure to provide a very clear and specific definition of what constitutes a problem. The first decision you may need to make for issues and problems is
whether or not to combine the management of issues and problems. Some reasons to consider whether or not to combine issue and problem management follow:
Can you create or obtain a single form and log that meets the needs of both issues and problems?
What is the size of your project? For a small project, you may want to combine issue and problem management, while you may want to separate them for a very
large project.
Every project has problems. Problems can be raised by any project stakeholder, including project team members, the client, third-party integrators, or vendors. Problems
need to be prioritized, assessed and resolved. The Problem Management Process should include the following:
Use of an Problem Form
Validate the problem to ensure results can be repeatable.
Prioritize problems, including establishing clear guidelines and definitions for discrete priorities (high, medium, low, etc.).
Assign the problem to a project SME.
Use of an Issue Log
Track and report problem status
Ensure the right resources are on this problem.
Time Resolution Procedures, including assigning a time for resolving the problem.
Monitor Procedures to ensure that the problem does not reoccur.
Document any roles involved and describe the responsibilities.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Problem Management requirements that should be taken into
consideration when developing the Problem Management Strategy.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IPM020_PROBLEM_MANAGEMENT_STRATEGY.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IPM.030 - DEVELOP ISSUE AND PROBLEM MANAGEMENT
SYSTEM
In this task, you develop the system to support and execute the Issue Management Process and the Problem Management Process documented in the Issue
Management Strategy and Problem Management Strategy. These processes contains the procedures for managing issues and problems during Project Execution and
Control. This includes identifying, assessing, approving, handling, tracking and reporting issues and problems.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Issue and Problem Management System - The Issue and Problem Management System incorporates the various pieces required for managing issues and problems
during the project. It includes the following components:
Issue/Problem Form
Issue/Problem Log
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Create or obtain a issue/problem form. Issue/Problem Form This form is used to capture individual issue/problem items as they are identified.
2 Create or obtain a issue/problem log. Issue/Problem Log This log is used to track all identified issues/problems.
Back to Top
APPROACH
The actual procedures for the Issue and Problem Management System are defined in the Issue and Problem Management Process components of the corresponding
Issue and Problem Management Strategies. The focus here is to support and execute those procedures. Generally, this involves obtaining or creating an Issue/Problem
Form and an Issue/Problem Log. Depending on whether or not you are combining or separating issue and problem management, you may need one Form and Log or a
separate Issue Form and Problem Form and Issue Log and Problem Log.
When obtaining or creating your forms keep in mind, at a minimum, the following information should be captured:
Issue/Problem ID - Each issue/problem should have a unique ID (e.g., I#### or P####).
Submitted By Enter the name of the person and/or organization who raised the issue/problem.
Date Submitted Enter the date the issue/problem was recorded in the Log.
Estimated Action Date Enter the date that the next action is expected on this issue/problem.
Impact Asses and document the impact to the project and/or business in terms of money, time, and/or quality.
Application/Flow/Module If applicable, enter the name of the application, flow, or module to which the issue/problem pertains.
Type Enter the type of issue/problem (e.g., technical, process, organizational, etc.).
Title Provide a short description of the issue/problem (usually a few words or a sentence, helpful when reporting issues/problems).
Description complete description of the issue/problem, the more details the better
Priority Indicate a priority (typically values could be critical, high, medium, low).
Escalation Indicate the current escalation level and anticipated date and level of next escalation.
Days Open Calculate the number of days this issue or problem has been opened.
Target Close Date Enter a target date for resolution.
Assigned To Enter who currently owns resolution of the issue/problem.
Status Enter the current status of the issue/problem (typical values are open or closed).
Action Plan/Comments Enter a detailed description of actions (including dates and owners) required to resolve the issue/problem.
The Form is used to raise an issue or problem and provide the basic information to start the process. The Log is used to track the progress and provide reporting.
Consider a central issue/problem repository for delegated project team members to log and update issues/problems, as required. Log all issues/problems, no matter how
minor. All team members, including the client team members, should have access to originate issues.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Issue Management Strategy
(IPM.010)
Problem Management Strategy
(IPM.020)
Use the processes defined in the Issue Management Strategy and Problem Management Strategy to develop the Issue and
Problem Management System.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IPM030_ISSUE_FORM.DOC MS WORD
IPM030_ISSUE_LOG.XLS MS EXCEL
IPM030_PROBLEM_FORM.DOC MS WORD
IPM030_PROBLEM_LOG.XLS MS EXCEL
RISK_ISSUE_PROBLEM_LOG.XLS MS EXCEL - This template provides a combined Risk, Issue and Problem Log.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IPM.040 - MANAGE ISSUES AND PROBLEMS
In the Manage Issues and Problems task, you put into practice the processes documented in the Issue Management Strategy and Problem Management Strategy and
manage any issues/problems as defined. This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MRIP Manage Risks, Issues and Problems
Back to Top
WORK PRODUCT
Managed Issues and Problems - Managed Issues and Problems is using the Issue and Problem Management System to execute the procedures documented in the
Issue Management Strategy and Problem Management Strategy to manage any issues/problems.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Perform an initial issues and problems assessment to identify issues and problems
using the Baseline Risk Assessment (RKM.020) and the Bid Transition collateral.
Issue/Problem
Form
An Issue / Problem Form is completed for each issue /
problem identified.
2 As issues/problems are identified, route them through the processes identified in the
Issue Management Strategy and Problem Management Strategy.
Issue/Problem
Form
Once an issue/problem is identified, complete an
Issue/Problem Form.
3 Add each issue/problem (completed Form) to the Issue/Problem Log and track its
progress. Identify owners and target resolution / fix timeframes
Issue/Problem
Log
Track all issues/problems from identification to
resolution.
4 Obtain client agreement and approval and sign off on any issue/problem resolution, as
necessary.
Issue/Problem
Resolution
Approval
Obtain any necessary sign-off to the Form or Approval
Certificate as defined in the appropriate process.
5 Implement approved resolution Issue/Problem
Log
Assign the work to the appropriate roles for completion
and update the Log to indicate resolution.
6 Escalate unresolved issues and problems. Issue/Problem
Log
Update the Log.
7 Track and report issues/problems. Issue/Problem
Log

Back to Top
APPROACH
Managing issues and problems consists of the following steps:
1. Conduct an initial issues and problems assessment and log any issues / problems uncovered.
2. Log all project issues/problems as they arise.
3. Prioritize, identify owners and target resolution/fix timeframes and assign issues/problems for closure.
4. Escalate unresolved issues/problems according to priority as previously defined in the Issue Management Strategy or Problem Management Strategy.
5. Track and report issue and problem status.
Discuss open issues/problems and log new issues/problems at project status meetings. Communicate high-priority issues/problems to the Executive Steering Committee,
as appropriate. Use the Log to provide metrics to the Executive Steering Committee regarding issues/problems opened, issues/problems closed, and aging of all open
issues/problems. These metrics should reflect an analysis of the issues/problems by priority.
Share all project issues/problems openly and frankly, and provide mechanisms for solutions. The important point to remember is not to let an issue/problem become a
discussion point that may negatively affect team performance. Identify, assess, share, and close issues/problems without making them personal with any team member.
Vocally reward team members for closing an issue/problem on time.
The output of this strategy is referred to as the Issue/Problem Log. Identifying, assessing and logging issues/problems should be a continuous process during the project;
the status of logged issues/problems should be shared at project status meetings.
The Issue/Problem Log is used to document the issues and problems that have been raised by project stakeholders and how they have been addressed. Stakeholders
should be involved in this issue and problem resolution process, as appropriate. Be sure to communicate the status and resolution of issues and problems to
stakeholders, particularly those who may not have access to the Issue/Problem Log, as defined in the Communication Plan.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Issue Management Strategy (IPM.010)
Problem Management Strategy (IPM.020)
Issue and Problem Management System
(IPM.030)
These work products document the strategy and processes for managing issues and problems during the project.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Issue and Problem Management.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
Use Issue Form created/edited in IPM030
Use Issue Log created/edited in IPM030
Use Problem Form created/edited in IPM030
Use Problem Log created/edited in IPM030
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IPM.050 - PRODUCE FINAL ISSUE AND PROBLEM REPORT
AND CLOSE LOG(S)
This task is executed in the Project Closure phase. It is a clean-up task to close the Issue and Problem Log(s) which includes all closed and any remaining open items.
This production officially closes the logs. Update the log(s) with any transitional information prior to closing or use the logs to create a Final Issue and Problem Report.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Issue and Problem Log
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Analyze any unresolved issues or problems. Issue/Problem Log
2 Update the Issue/Problem Log or produce Final Issue
and Problem Report.
Final Issue and Problem Report
Final Issue/Problem Log
Update the log with any pertinent transitional information or produce a
separate report.
3 Close Issue/Problem Log. Closed Issue/Problem Log
4 Document any lessons learned. Issue and Problem Management
Lessons Learned
This report is used to create the Lessons Learned report produced in
the Communication process.
Back to Top
APPROACH
Analyze the Issue/Problem Log and consider the business impact and risk of any unresolved issues. Document this analysis in the log or create a separate Final Issue
and Problem Report. Provide this information to the client and transition the Issue and Problem Management System to the client.
Note: The resolution of remaining open issues may present additional business opportunities.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IPM050_ISSUE_AND_PROBLEM_MANAGEMENT_LESSON_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[STM] STAFF MANAGEMENT
Your project is a mini organization unto itself and should be treated as such. The Staff Management process focuses on the following:
plan resource requirements
identify, document, and assign roles, responsibilities, and reporting relationships for the project team members
evaluate the skills required to deliver the project
manage the project team
release staff
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
As part of Project Start Up, the project manager needs to identify, document, and assign roles, responsibilities, and reporting relationships for the project team members,
including Oracle, client and sub-contractors (if used). You must work closely with consulting managers and consulting resource managers within Oracle (and similar
managers, if working with a partner or contractor) and within the clients organization, to staff your projects with the people who have the skills and knowledge you
require. Document your findings in the Resource Plan.
Next, the project manager must evaluate the skills required to deliver the project (within the agreed upon scope) and develop the Staff Management Plan translating those
skills into project roles. From there, the project manager should source, select, and schedule qualified individuals to fill the agreed upon project roles. These people
should be organized into a cohesive team with assigned roles and responsibilities, and given the tools and information required to perform their assigned tasks. The
project manager assesses the skills of the team members and develops training plans, as required.
This process should include the entire organization of the project, the internal project team, the sponsors, the key stakeholders, the support personnel, and everyone else
who will play a role in getting the project to closure or be responsible for assuming control of the application once the project is completed.
Project Execution and Control Phase
During the Execution and Control phase, the project manager is responsible for managing and leading the project team and for understanding the status of the work they
are performing as well as any issues they may have. The project manager must also work within the defined governance model to ensure that everyone is kept informed
and that the project stays on track.
The project manager also monitors the progress of training and mentoring activities during this phase.
As new team members join the project and others leave, the project manager is responsible for ensuring that there are smooth and seamless transitions.
Project Closure Phase
During Project Closure, the project manager is responsible for ensuring that resources roll off smoothly, that work was performed and documented as planned, and that
knowledge sharing to the successors has occurred. The project manager documents the resources' performance and shares it with the resources' managers.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS STM.010 Plan Resource Requirements Resource Plan Y Core
PS STM.020 Develop Staff Management Plan Staff Management Plan Y Core
PS STM.030 Staff Project Staffed Project Y Core
PS STM.040 Prepare Orientation Guide Orientation Guide Core
Project Execution and Control
PEC STM.050 Conduct Team Orientation Oriented Team Core
PEC STM.060 Manage Project Team Managed Project Team Core
Project Closure
PC STM.070 Release Staff Released Staff Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager

Client (User)
CPS Client
Project
Sponsor

Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.010 - PLAN RESOURCE REQUIREMENTS
In this task, develop the project team structure and reporting hierarchy as well as identify the roles and responsibilities required to complete the project.
Resource planning begins with validating that the resource requirements identified during the Bid Transition process are appropriate to meet project needs. The Validated
Scope and detailed Project Workplan are key inputs to this task. As the project progresses, it may be necessary to update the Resource Plan to accommodate evolving
requirements. Resource updates that would affect the project budget must be discussed with the client and handled through the Scope Management process. (Refer to
the Scope Management Process.)
ACTIVITY
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
WORK PRODUCT
Resource Plan - The Resource Plan documents the project team structure and reporting hierarchy and the roles and responsibilities required to complete the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Develop the project team structure and reporting hierarchy. Project Team Organization
Chart
Document the structure and hierarchy in an organization
chart.
2 Identify the roles and responsibilities required to complete the
project.
Resource Plan
3 Obtain approval from key stakeholders. Approved Resource Plan Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Your project is a mini organization unto itself and should be treated as such. During Project Start Up, identify, document, and assign roles, responsibilities, and reporting
relationships for the project team members.
Define the skills and knowledge considered necessary to meet the projects requirements and determine the length of time those people will be required. A good
starting point is the response Oracle sent to the RFP. A high-level project schedule is typically included. It specifies the resources and time commitment, based
on the modules being implemented. Resumes of Oracle consultants matching the skills and knowledge required are attached. Determine timing for when each role
should be filled and the duration to support the Project Workplan. (Refer to the Work Management process.)
Determine the reporting relationships required among the different groups or individuals assigned to the project.
Identify the approximate number of resources on each sub-team and the relationships between each sub-team.
Identify roles that will be staffed by the client, Oracle, or a third party. Format this information into an organizational chart for clarity. Review organizational charts
with the client to obtain consensus. Ensure the client has resources in some key positions.
Identify any constraints that might limit how the project team is organized. Again, use the RFP or the response to the RFP to gather as much information as you
can about the organization, its employees, and any external groups, such as unions, that may have an impact on your project.
Determine the availability of the resources you require from the customer and Oracle. The best way to staff your project is with consultants assigned to your
project full time and customer experts for the duration required.
Third-party resources may be necessary to meet resource requirements. (refer to Procurement Management).
Work with team leads to detail roles and responsibilities for each team member. Roles and responsibilities for each team member should include: skill set and job
requirements, major work product responsibilities, project team role and team interaction expectations, and status reporting responsibilities.
The result of planning is an understanding and articulation of the detailed roles, responsibilities, and reporting relationships required for the project.
Back to Top
SUPPLEMENTAL GUIDANCE
Cloud Roadmap
This task has supplemental guidance that should be considered if you are performing an engagement using the Cloud Roadmap service offering. Use the following to
access the task-specific supplemental guidance. To access all Cloud Roadmap supplemental information, use the Cloud Roadmap Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Validated Scope (SM.010
Project Workplan (WM.030)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
STM010_PROJECT_TEAM_ORGANIZATION_CHART.DOC MS WORD
STM010_RESOURCE_PLAN.XLS MS EXCEL
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.020 - DEVELOP STAFF MANAGEMENT PLAN
The objective of the Develop Staff Management Plan task is to develop and document the following components:
Resource Requirements (refer to STM.010 - Plan Resource Requirements)
Staff Performance Expectations
Retention and Recognition Plan
Performance Appraisal Plan
Poor Performance Remediation Plan
Mentoring Plan
Individualized Training and Skill Building Plans
The Staff Management Plan is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Staff Management Plan - The Staff Management Plan documents the staff requirements, performance expectations, and various staffing plans. The Staff Management
Plan is a key component of the Project Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Use the Resource Plan to determine resource
requirements.
Resource Requirements Document the resource requirements.
2 Determine staff performance requirements. Staff Performance Requirements Document the performance requirements.
3 Obtain retention commitments and design
recognition activities and plan.
Retention and Recognition Plan Obtain written retention commitments. Plan and document team building
activities and recognition plans.
4 Develop Performance Appraisal Plan. Performance Appraisal Plan Document the Performance Appraisal Plan.
5 Develop staff remediation plan. Poor Performance Remediation
Plan
Document the remediation plan.
6 Develop mentoring plan. Mentoring Plan Document the Mentoring Plan.
7 Develop training and skill building plans. Individualized Training and Skill
Building Plans
Document training and skill building plans.
8 Obtain approval from key stakeholders. Approved Staff management
Plan
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Staff Performance Expectations
Document and communicate expectations for team member performance, such as, timeliness, adherence to the work plan, travel, etc.
Manage to a budget and ensure that you do not overrun the budget unless there is adequate justification in advance. Get buy-in from the project team early on to
ensure they will cooperate with this.
Monitor other rules of engagement. The customer may have special hotel rates or guidelines they wish the consultants to follow. Failure to comply with reasonable
customer requests causes unnecessary friction.
Establish procedures for deviation from expectations.
Retention and Recognition Plan
Obtain a commitment that the team members will not be removed from the project until you are satisfied that they can be released. This commitment should come
from the customer for staff they have dedicated to the project; from the consulting resource manager for Oracle staff; and from the managers for the partners staff.
Build in time in the project for team building activities to foster a cohesive work environment. The activities should include all team members (Oracle, client and
third-party).
Keep the team challenged. Give them an assignment that you know will stretch their skills and knowledge.
Recognize accomplishments as they are completed. Task and milestone completion deserve recognition.
Keep the team informed of the progress of the project. Team members do not like surprises any more than you do. Tell them how they are progressing. This is
helpful for those periods when you may require them to work longer hours to meet a deadline.
Get their buy-in and solicit their opinions. This will make the team members feel like full contributors to many facets of the project. Their experience and opinions
may give you added perspectives when dealing with certain challenging situations.
Performance Appraisal Plan
Work with resource managers and team member managers to define procedures for documenting performance.
Build time into the schedule to ensure team members are given timely and accurate reviews.
Poor Performance Remediation Plan
Work with the team member to establish a plan for correcting poor performance.
Monitor and document progress on a weekly basis. Decide quickly if the team member is not the right fit for the position and replace as needed to mitigate delays in
the project schedule.
Mentoring Plan
Mentoring is also about nurturing the talents of those who are assigned to the project team. Take the time to find out what the members of your team would like to
accomplish on this project. Look for opportunities where you might be able to accommodate their desire to try something new. Assist them whenever possible to
enhance their skills and abilities.
Match team member skill sets to ensure junior team members have access to senior team members as needed. This is an excellent way to ensure the client team
members are learning the necessary skills and knowledge sharing is occurring.
Have senior team members regularly meet with junior team members to ensure work is completed on time and is the best approach from a functional and technical
perspective.
Individualized Training and Skill Building Plans
Refer to the skills required by role, as defined in the Resource Requirements component, to identify gaps in knowledge areas and develop individualized training
plans. Functional skills depend on the scope of the project and the software applications being implemented. Technical skills include database, operating system,
network, programming, and web development.
Coordinate client training with the client and the implementing organization's training department to plan training for client team members. It is recommended that
the client take the initial or introductory training as early as possible and take the more advanced classes after they have spent some time working with the
application.
Review the project lifecycle and identify the milestones where specific skill sets by role will be needed.
Determine the number of training participants, the length of time they will be involved in training, and when the training should most appropriately take place.
Research alternative training opportunities, review course schedules, and create a training plan to include each members courses and dates. Plan training early to
ensure availability.
Ensure the work plan reflects team member training and that team members attend training as scheduled.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive
activities, tasks or task steps. If your project does not have a dedicated project administrator, the project manager
would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Resource Plan (STM.010) Use the Resource Plan to determine resource requirements.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
STM020_STAFF_MANAGEMENT_PLAN.DOC MS WORD
STM020_STAFF_TRAINING_PLAN.DOC MS WORD
STM020_STAFF_MANAGEMENT_PROCEDURES.DOC MS WORD (Former PJM2.6.1 Template)
STM020_PROJECT_ROLES_AND_RESPONSIBILITIES.PPTX POWERPOINT (Former Compass Template/Example)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.030 - STAFF PROJECT
Staffing the project addresses the issues that influence getting the right people for the project.
ACTIVITY
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
WORK PRODUCT
Staffed Project - The Staffed Project is the assigning of resources (people) to the roles defined in the Resource Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify resources to fill the project roles. Staffed Project
Back to Top
APPROACH
Staffing the project involves:
Identifying team leads for each sub-team and detailing responsibilities for team leads.
Working with team leads to detail roles and responsibilities for each team member. Roles and responsibilities for each team member should include: skill set and
job requirements, major work product responsibilities, project team role and team interaction expectations, and status reporting responsibilities.
Associating the roles with specific tasks and activities in the project work plan and project budget in order to develop an overall resource plan. The resource plan
will highlight what resources are needed and when they are needed. (refer to Work Management).
Reviewing sourcing strategy with client.
Identifying available Oracle resources with appropriate skills.
Working with the client to secure required client resource commitments.
Working with Procurement to fill third-party roles, if necessary.
Making final determination of project resources and obtaining schedule commitments.
Adjusting Project Workplan based on resource training, vacations and other commitments.
Getting the right people for projects can sometimes be a challenge. You must work closely with consulting managers and consulting resource managers within Oracle
(and similar managers, if working with a partner or contractor) and within the clients organization, to staff your projects with the people who have the skills and knowledge
you require. At times you may find you have inherited a project team consisting of Oracle resources, client technical resources, partner resources, Contracting Service
Providers, independent consultants, and users the client has chosen to represent the user community. In this situation you should:
Determine whether you have the right people. Start with the Resource Requirements from the Staff Management Plan. Compare the skills and knowledge of the
people on the team with the skill requirements in the plan. Talk to each member of the team to gather all the information you require to complete your comparison.
Determine that there is the correct number of people. Again, using the tools mentioned above, make sure that there are enough team members for the tasks to be
completed.
Completing these two tasks will enable you to assess if you have the right people with the right mix of skills. If a particular team member has a weakness in a particular
area, assigning them to assist a more knowledgeable team member may give you two very strong people at a later point in the project.
Remember that during a project there is a vast amount of knowledge sharing and skill enhancement. Take this into consideration when you assess your team. This is
especially true of the users assigned to the project team, assuming they have been sent to the appropriate Oracle training classes.
If adequate resources cannot be obtained, either from the client, the third-party or Oracle, an issue must be created and managed, as it may impact project timelines.
(refer to Issue Management).
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Resource Plan (STM.010) Use the Resource Plan documents to identify the project team structure and reporting hierarchy and the roles and responsibilities
required to complete the project.
Staff Management Plan
(STM.020)
Use the Staff Management Plan to match staff to requirements and performance expectations.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Staff Management.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.040 - PREPARE ORIENTATION GUIDE
In this task, develop a comprehensive team member Orientation Guide to be used during Project Kickoff and afterward for the on-boarding of new team members. This
will help to streamline the on-boarding process, ensure consistent communications and reduce the project manager and team leads' workload during the on-boarding
process. Depending on your project, you may decide to produce multiple guides tailored to a specific process (e.g., Scope Management) or for a specific audience
(Oracle, client, or sub-contractor team member), or for any other reason deemed appropriate.
ACTIVITY
PS.ACT.DSPB Develop Staff Plan and Budget
Back to Top
WORK PRODUCT
Orientation Guide - The Orientation Guide is a comprehensive document that includes pertinent information for project team members. Initially, it is used during Project
Kickoff and and then made available for new team members that join the team after Project Kickoff. Depending on your project, you may decide to produce multiple
guides tailored to a specific process (e.g., Scope Management) or for a specific audience (Oracle, client, or sub-contractor team member), or for any other reason
deemed appropriate.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Gather team member information. Team Member Introduction Document biographies of key members.
2 Produce team contact information. Team Contact List Document a listing of all team members with contact information (phone number,
email, cell number, etc.)
3 Produce logistic information. Logistics Document any directions, etc.
4 Highlight important contract information. Contract Deliverables and Terms
and Conditions
Highlight any relevant contract information for the project team.
5 Produce appropriate Project Management
Plan components
Project Management Plan (PJM
Process Component) Guidelines
Compile and document relevant information for each PJM process as
appropriate for your project (e.g., Scope Management, Work Management.
etc.).
6 Gather any reporting guidelines that were not
already covered in previous components.
Reporting Guidelines Document any reporting guidelines that were not already covered in previous
components.
7 Gather any pertinent team meeting
information.
Meeting Schedules Produce a calendar or listing of all team meetings.
8 Compile all components into one guide. Orientation Guide Organize all components into a cohesive Orientation Guide and provide a table
of contents.
Back to Top
APPROACH
Your project Orientation Guide should be tailored to your project. Including a section for each process may be pertinent for a large project, but not necessary for a small
project. Even on a large project, some process overviews may not be needed. Make the various PJM process work products available to all team members and reference
them in your guide rather than repeat information already documented. As with tailoring the sections you include in your Orientation Guide, you may also decide to
produce multiple guides tailored to processes, audience or some other appropriate reason. The following is a suggested format for an Orientation Guide:
Team Member Introductions
Team Contact Information, Key Contact List (phone numbers)
Logistics - Directions Contract Deliverables and Terms and Conditions
Scope Management - Project scope, objectives, and approach
Financial Management
Work Management - Project organization, Time and Expense Reporting Guidelines, Work Rules, Project Workplan and timeline, Key Risk Management Work
Products
Issue and Problem Management
Staff Management
Communication Management - Communication Plan
Configuration Management Infrastructure Management
Procurement Management
Organization Change Management Reporting Guidelines
Meeting Schedules
As necessary, update the Orientation Guide throughout the duration of the project so that it will be up-to-date new members who join the team.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
SM.010 Validated Scope (SM.010)
Scope Change Management Processes (SM.020)
Financial Management Plan (FM.020)
Work Management Plan (WM.020)
Project Workplan (WM.030)
Risk Management Plan (RKM.010)
Risk Management System (RKM.030)
Issue Management Strategy (IPM.010)
Problem Management Strategy (IPM.020)
Issue and Problem Management System (IPM.030)
Staff Management Plan (STM.010)
Communication Plan (CMM.020)
Infrastructure Management Plan (IFM.010)
Procurement Strategy and Process (PCM.010)
Client's Organizational Change Management
Strategy (OCHM.010)
These work products contain the pertinent information for project team members that needs to be compiled
into the Orientation Guide.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
STM040_PREPARE_ORIENTATION_GUIDE.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.050 - CONDUCT TEAM ORIENTATION
In this task, plan and conduct a Project Kickoff meeting to orient the team to the project. If necessary, similar orientation meetings can be given for new team members
that join the project after kickoff. This meeting will help streamline the on-boarding process, communicate the project objectives and structure, and begin to develop
cohesion among the team. Use the Orientation Guide to help structure the meeting and plan presentations. Depending on your project, you may decide to hold multiple
Project Kickoff meetings tailored to a specific process (for example, Scope Management) or for a specific audience (implementing organization, enterprise, or sub-
contractor team member), or for any other reason deemed appropriate.
Again, depending on the project, additional orientation meetings may not be feasible, make the Orientation Guide and Project Kickoff Presentation available to all new
team members that join the project after kickoff.
ACTIVITY
PEC.ACT.OMT Orient and Manage Team
Back to Top
WORK PRODUCT
Oriented Team - The Oriented Team is a project team that has received the Orientation Guide and participated in a Project Kickoff or team orientation meeting`where the
project objectives and structure have been communicated.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify audience. Attendees List Create a list of all attendees.
2 Schedule meeting and provide for
meeting infrastructure.
Project Kickoff
Schedule and
Infrastructure
Determine the date, time and place for the meeting. Make arrangements for appropriate seating, equipment
(screen, flip charts, etc.). Make lunch arrangements.
3 Set meeting schedule. Project Kickoff
Agenda
Use the organization of the Orientation Guide to develop the presentation. Individual presentations can be
developed for each component of the Orientation Guide by the leads for each area. All the presentations
combined become the Project Kickoff Presentation.
4 Create Kickoff presentation. Project Kickoff
Presentation

5 Conduct Team Orientation Meeting. Oriented Team
6 Make Project Kickoff Presentation
and Orientation Guide available for
new staff, as needed.
Published
Orientation
Materials
This may mean organizing all the individual component presentations into some sort of organized file
structure. Make sure copies of the Orientation Guide are available to new staff.
Back to Top
APPROACH
Identify Audience
Work with the client to identify the audience, to schedule client attendance. You need to know how many people will be in attendance.
Schedule Meeting and Provide for Meeting Infrastructure
Work with the client to set the date, time and place for the meeting. Obtain appropriate facilities to accommodate the number of attendees. Prepare for any needed
equipment (projectors, screens, flip charts, etc.). Make food and drink arrangements. Make arrangements to have enough copies of the Orientation Guide for each
participant.
Set Meeting Schedule
Use the organization of you Orientation Guide to help set the meeting schedule.
Arrange for the project sponsor to provide either opening or closing remarks to the project team. Remarks should emphasize the client's executive management support to
the project team as well as the significance and impact of the project on the client and its operations. Advanced planning may be necessary to ensure the appropriate
client executives are available to speak at the orientation meeting.
Create Kickoff Presentation
The project manager should oversee development of orientation meeting materials and ensure presentation materials are prepared, including presentation slides,
attendee materials, and flip charts. Use the organization of the Orientation Guide to develop the presentation. Have team leads create the presentation for their areas and
lead the presentation of their area during the meeting. For example, the team lead for Scope Management is responsible for developing the presentation to communicate
the Validated Scope and Scope Change Management Processes to the members as well as presiding over the presentation .
Conduct Team Orientation Meeting
Distribute the Orientation Guide and any other orientation meeting materials.
Allow each team member to introduce themselves and the role they will play on the project.
Capture any issues and concerns that cannot be addressed during the meeting and establish a plan to respond back to the team.
Make Project Kickoff Presentation and Orientation Guide Available
After the initial Project Kickoff Meeting, it may not be feasible to hold additional meetings as new staff join the project. Make the Project Kickoff Presentation and the
Orientation Guide available to new staff as they join the project.
Other Considerations
Review the project team Communication Plan to ensure the orientation meeting adheres to standards already discussed with and agreed upon by the client.
Include time in the Project Workplan for the orientation meeting so that it does not conflict with other team member assignments.
Back to Top
SUPPLEMENTAL GUIDANCE
SOA Engineering Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Engineering
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA
Engineering Planning Supplemental Guide.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Orientation Guide (STM.040) Use the Orientation Guide to help structure the meeting and plan presentations.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Service Architecture Review this technique as input into this task.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
STM050_PROJECT_KICKOFF_ORIENTATION.PPTX POWERPOINT
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.060 - MANAGE PROJECT TEAM
In the Manage Project Team task, you put into practice the procedures documented in the Staff Management Plan and manage the staff. This includes the following
activities:
Conduct regular staff meetings.
Review and respond to team status reports.
Maintain the resource plan,
Advise client project manager or appropriate client project sponsor if there are any issues relative to client team member performance.
Provide regular performance feedback to both individuals as well as Oracle line management.
Retain and develop project team members.
Plan for resource roll offs.
Release resources as required.
This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.OMT Orient and Manage Team
Back to Top
WORK PRODUCT
Managed Project Team - The Managed Project Team is a staff that is managed using the procedures documented in the Staff Management Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Conduct regular staff meetings. Individual Status
Reports
These are typically one-on-one or group meetings separate from project status meetings.
2 Review and respond to team status reports. Team Status
Reports
Allow staff members room to present their issues and concerns in status reports. Do not
distribute individual status reports.
3 Review and respond to team status reports. Team Status
Reports
Allow staff members room to present their issues and concerns in status reports. Do not
distribute individual status reports.
4 Maintain the Resource Plan Updated
Resource Plan
Keep track of team members' start and stop dates and any planned time off.
5 Advise client project manager of client team
member performance issues.
Any client team member performance impacting project schedule or quality should require a
change order.
6 Provide regular performance feedback. Performance
Appraisals

7 Retain and develop project team members. Retention Plans
8 Plan for resource roll-offs. Updated
Resource Plan
Give reasonable notice to Oracle management and resource managers of the resources being
released. (Refer to STM.070 - Release Staff.)
9 Release resources, as required. Updated
Resource Plan
Not all resources are released at Project Closure. (Refer to STM.070 - Release Staff.)
Back to Top
APPROACH
Conduct Regular Staff Meetings
Regular staff meetings provide a forum for the project manager and the team member to discuss the team member's perspective on how the project is proceeding
and how the team member's tasks are proceeding. If these meetings are not scheduled, they typically don't happen.
Encourage the team member to share thoughts and concerns that he or she may be reluctant to share in a group atmosphere.
Review the team member's work schedule and capture any changes to the planned work schedule.
Commit to following up with any issues or concerns that could not be addressed during the meeting and establish a time and means for getting back to the team
member with the results.
Review and Respond to Team Status Reports
Have team members complete status reports on a weekly basis, detailing the tasks they have completed, the tasks they plan to complete, any deviations, and any
issues or concerns they may have in completing their tasks.
Be sure to read the status reports on a timely basis and provided feedback on their issues and concerns.
Use the team members' status reports as input to the team's status report that is widely distributed. Do not distribute individual status reports
Maintain the Resource Plan
Keep track of team members' start and stop dates and any planned time off.
Advise Client PM of Client Team Member Performance Issues
Provide specific facts when presenting performance issues of a client team member.
Be constructive and provide alternatives to getting the team member back on track.
Communicate the impact to the project if corrective action is not taken.
Keep in mind that the issue is not the client's problem but a project problem and that you are willing to assist in the solution.
Provide Regular Performance Feedback
There may be a time when a team member is not the right fit for the project. To be fair to the individual and to the success of the project, once identified, the
individual should be removed from the project and replaced as soon as possible. This is by no means an easy task. As the project manager, you must:
Document the reasons why you feel the person is not the right fit for the project. Be constructive and keep the comments job-related.
Speak to the team member about their performance. Perhaps there are some underlying issues, such as personal illness, family illness, or travel that could be
having a negative impact on the work being produced by this individual.
If the team member is from Oracle, first discuss your observations with them. Hard personnel issues are best handled first thing in the morning, not in the evening
when you and your team member are tired. If a satisfactory conclusion cannot be reached, discuss your concerns with the employees manager and determine
possible solutions. The consulting resource manager can also help find a replacement, if required.
If the team member is from a partner, speak with their manager and customer management about your concerns and about a replacement.
If the team member is not an employee, you should work out an exit plan with the individual and begin to search for a replacement, either from Oracle, the partner,
or outside resources. There may have been very valid reasons why a subcontractor was hired for the project and those same reasons may bind you to finding a
similar replacement. These rules should be defined when the resource plan is being finalized.
Retain and Develop Project Team Members
You have all the right people on your project team. Now, how do you keep them? A couple of suggestions:
Obtain a commitment that the team members will not be removed from the project until you are satisfied that they can be released. This commitment should come
from the client for staff they have dedicated to the project; from the consulting resource manager for Oracle staff; and from the managers for the partners staff. It is
not as simple with independent consultants.
Give the team the support they require.
Keep the team challenged. Give them an assignment that you know will stretch their skills and knowledge.
Keep the team informed of the progress of the project.
Get their buy-in and solicit their opinions. This will make the team members feel like full contributors to many facets of the project. Their experience and opinions
may give you added perspectives when dealing with certain challenging situations.
Recognize your team when their deadlines or milestones are met. Make sure you send a copy to their manager or direct report.
Encourage the team members to spend social time (i.e., lunch, coffee break, ice cream break) with customer team members, extended team members, and
partners. Relationship building makes the project much more fun and interesting.
Follow the skill development and mentoring plans as defined in the Staff Management Plan prepared in step STM.020 - Develop Staff Management Plan.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Staff Management Plan (STM.020) The Staff Management Plan documents the various plans for managing staff during the project.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
STM060_INDIVIDUAL_STATUS_REPORT.DOC MS WORD
STM060_ASSIGNMENT_REQUEST.DOC MS WORD (Former PJM 2.6.1 template)
STM060_ASSIGNMENT_TERMS_OF_REFERENCE.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
STM.070 - RELEASE STAFF
The goal of this task is to effectively release staff. Resources are released from the project throughout the project lifecycle. In most cases, the release dates are known
and documented as part of task STM.030 - Staff Project. Follow the same procedures whether the resource is leaving during the project or at Project Closure. However,
during Project Closure all remaining staff is released.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Released Staff - Released Staff are staff that have been released from the project and been given a performance appraisal (or some other form of performance feedback
to their manager for consideration in future performance appraisal).
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Plan for resource roll offs. Updated Resource Plan
2 Release resources, as required. Updated Resource Plan
3 Prepare project performance appraisals. Performance Appraisals/Feedback
Back to Top
APPROACH
Plan for Resource Roll Offs
Give reasonable notice to the management that owns the resource and the resource managers of the resources that are being released.
Allow adequate time for knowledge sharing before the resource leaves. Include time in the Project Workplan for the resource that is leaving and the resource that is
taking over the responsibility to conduct hand-over. It is best when there is time allowed to have a proper transition session.
If the resource is leaving the project before deployment, review staffing requirements to finish the project. It is always ideal to keep resources for the duration of the
project. If it is possible to assign the resource additional tasks and extend the resources end date, negotiate the change with the organization owning the resource
and the resources manager.
Release Resources, as Required
Review the resources tasks and related documentation for completeness before the resource leaves.
Verify that knowledge sharing has occurred with the resource that is assuming responsibility for the work.
Recognize the resource's contribution to the team.
Prepare Project Performance Appraisals
Provide feedback on all aspects of the resource's performance: adherence to project procedures, task completion, quality, willingness to help others, flexibility,
product knowledge, ability to communicate (orally and in writing), relationship with client, professionalism, conduct, administrative task completion, etc.
Document performance throughout the project, especially significant achievements and deviations from expected results, to facilitate the preparation of the
performance appraisal. Relying on memory can lead to inaccurate and unfair representations of performance.
Discuss deviations from expected results as they occur and include the resource's manager, as appropriate. The resource and the resource manager should not be
learning about the deviation for the first time in a performance appraisal. Note when corrective action was successful in getting the team member back on track.
Provide feedback to resource managers for interim reviews, as requested.
Solicit feedback from team leads when preparing appraisals for resources in their sub-teams.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[CMM] COMMUNICATION MANAGEMENT
The Communication Management process is focused on the internal project team communications to key stakeholders regarding progress and status. This process does
NOT address the broader set of communication typically associated with Organizational Change Management. Please see the Organization Change Management
process for steps in setting up organizational communication. Organizational Change Management is also addressed within the Organizational Change Management
process embedded in the Envision (EOCM) and Implement (OCM) focus areas. Therefore, these processes should be coordinated to avoid overlap or confusion.
Effective project communications require consistent, accurate and complete reporting of progress and status. Of the facets of Project Management, communications
planning is one of the most critical to success. The project manager is responsible for developing a Project Team Communication Plan, training the project team in the
plan's importance and maintaining the Project Team Communication Plan.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
Communication Management begins with the first client contact and continues to evolve throughout the project life cycle. Project communications is a critical function in
any project and a formal method must exist for effective communications with project stakeholders, including the client, project team members and other interested
entities. Developing a Project Team Communication Plan requires the same thoroughness of planning and execution as any other facet of the project. Routine and
predictable communications must be discussed, documented, and agreed to during Project Start Up.
During the Project Start Up phase, the project manager is responsible for defining the overall strategy for communicating and sharing project information. This includes
documenting and agreeing with key stakeholders concerning the:
Who? What audience and which individuals will receive the communication? Who will provide information necessary for the communication?
What? What information is the audience looking for? If the communication is addressed to the project Steering Committee, project progress to plan,
budgetary information, issues, and tactical plans for the next reporting period might be appropriate. Communications directed to Portfolio Directors
might include personnel performance, staff projections and internal communications. Communications for senior-level client executives should focus
on concerns at a management level.
Why? Why is the communication being prepared? Will it communicate weekly status to the core team and Steering Committee or announce the completion
of a major milestone to management and end users? Objectives of the communication must be clearly stated when the communication is written.
When? When is the communication needed? Communications submitted too late to be of value in decision-making are wasted efforts and may cause
problems. If the information is needed immediately, the communication should be ready. As with any plan, frequency and timing are keys to success.
How? How should the information be presented to best meet the needs of the audience? What media will be used: reports, meetings, email, etc?.
Communications can be verbal, written, or include a combination of both. Verbal communications can be formal, including a prepared discussion
using formal reports and visual aids, or informal as in a round table discussion. If informal communications are used, all significant conversation,
issues, and decisions must be documented with a follow-up memorandum to the participants, the project managers project diary, and the core team.
Project communication activities typically include but are not limited to:
Reports:
Scheduled, Written Status Reports
Financial Reports
Profiles
Project Reviews
Meetings:
Project Launch Communications/Kickoffs
Scheduled Status Meetings
Scheduled Steering Committee Meetings
Project Execution and Control Phase
Following the strategy, processes, and procedures defined in the Project Team Communication Plan developed in the Project Start Up phase, the project manager must
ensure smooth, concise, and effective communications are occurring at all levels of the project. Its important that all project stakeholders; users and project team
members are informed about the project activities and status. Prior to go-live, it is especially critical to have a strong Communication process in place so that all project
participants are fully aware of critical project activities.
Execution of most Project Team Communication Plans is an on-going process. Like so many components of project operations it needs to have a regular, recurring
schedule that is communicated as well.
Occasionally you will miss a scheduled communication. It can be very satisfying to have someone mention that they noticed that it had not shown up on time. That means
that not only are people reading your communications, but they are looking forward to receiving them!
Dont fall into the trap of only communicating at set times. Be aware of opportunities to communicate (and be communicated to) that are not planned. Project managers
should have their elevator speech ready if someone asks them for a few impromptu words about their project. Likewise, when you overhear adverse comments being
made, pay attention. Unsolicited communications can alert you to a situation you may never have uncovered through planned communications.
Management by walking around is an excellent form of communication with team members. The focus of this day-to-day activity is to engage in brief informal
discussions to assess progress or problems and observe productivity. A good opening for these conversations is, Hows it going today?
Make time for informal group feedback. There are always external factors that impact project success. Ask what concerns the group has, what rumors they may
have heard. You may be able to provide direction on a stalled activity by removing misconceptions or ambiguities.
Effective project communications require consistent, credible, logically structured and concise reporting of project progress and status. Credibility is key here. Clear, direct
communications on the projects direction, progress and health are critical to success. These two quotes sum up the value of credibility:
For every week of upset you avoid by hiding the truth, you gain a month of bitterness and mistrust. Besides, the grapevine already has the news, so dont imagine that
your information is a secret. - William Bridges
Saying what you think you are expected to say has several drawbacks, you may get the expectation wrong, the expectation may change, it is difficult to keep clear what
you've said in the past, especially when expectations keep changing, it destroys your mind and spirit. Telling the truth is often the most powerful action you can take. -
William Bridges.
Project Closure Phase
At the conclusion of the project, a Lessons Learned report and other Final Reports (project status, etc.) must be written and compiled and key project documentation must
be turned over to the client. Ensure that the client and/or partner have been given the appropriate work products and then remove client and partner access to any
internal systems.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS CMM.010 Conduct Project Stakeholder Analysis Project Stakeholder Analysis Core
PS CMM.020 Develop Project Team Communication Plan Project Team Communication Plan Core
Project Execution and Control
PEC CMM.030 Manage Project Team Communication Project Team Communication Core
Project Closure
PC CMM.040 Document Lessons Learned Lessons Learned Y Core
PC CMM.050 Turn Over Project Documentation Project Archives Y Core
PC CMM.060 Submit Final Reports Final Reports Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager

TM Team
Members
Publish individual reports, distribute and file. Participate and share views on what worked and what could be improved.
Client (User)
CPS Client
Project
Sponsor

CPM Client
Project
Manager

Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CMM.010 - CONDUCT PROJECT STAKEHOLDER ANALYSIS
Stakeholders are those entities (a person, group or department) whose interests and expectations need to be taken into account when making key project decisions.
Alternatively, a stakeholder is someone who has a vested interest in your project or will be affected by its outcomes.
The Project Stakeholder Analysis is an important prerequisite to the Project Team Communication Plan (CMM.020). In this task, the goal is to identify the project
stakeholders, determine their influence, concerns and interest in the project, determine what information they would like to receive and by what method of delivery. The
Project Stakeholder Analysis should be incorporated into the project's overall Project Team Communication Plan, which is a component of the Project Management Plan.
ACTIVITY
PS.ACT.VSSOS Validate Scope, Stakeholders and OCM Strategy
Back to Top
WORK PRODUCT
Project Stakeholder Analysis - The Project Stakeholder Analysis documents the project stakeholders, their influence and interest in the project, what information they
would like to receive and by what method of delivery.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Review
previously
gathered
information.
None Review the Identified Project Stakeholders from Bid Transition and any other pertinent information.
2 Identify key
stakeholders.
Stakeholder or
Stakeholder Group
Begin with C level executives but extend the assessment to cover all groups significantly affected by the project and/or
who can influence its outcome. Remember that stakeholders can be external to the entity you are working with and that
these needs need to be passed on to the Organizational Change Management process.
3 Assess project
impact on each
stakeholder.
Organizational
Change
Management
Impact
Think about the project impact on stakeholders in broad business terms. Typically, larger projects drive significant changes
in business processes, roles and responsibilities, organizational structures and technology usage.
4 Assess
stakeholder
interest /
influence and
concerns.
Importance/Influence
/Concerns
During Project Start Up, solicit input from the client project manager and functional/business unit heads regarding their
views on project impact and the roles their groups should play. Recognize that a stakeholder group's perception of the
project's impact and the significance of their role in the project can be surprisingly different from the project team's. See
Tools for one way to address this.
5 Prioritize
stakeholders.
Prioritized
Stakeholders
The Prioritized Stakeholders show which stakeholders have the greatest influence on the project.
6 Assess the
frequency of
reporting for
each
stakeholder.
Frequency Document the frequency of reporting for each stakeholder.
7 Determine
informational
needs of each
stakeholder.
Information Desired Determine what information each stakeholder wishes to receive. Similar stakeholders should be grouped together to
reduce the number of communications required.
8 Determine the
delivery method
for each
stakeholder.
Delivery Method Determine the preferred delivery channels, (e.g., email, newsletter, etc). Similar stakeholders should be grouped together
to reduce the number of communications required.
Back to Top
APPROACH
This task should be conducted as early in the project as possible during Project Start Up. Often this activity is conducted in an initial Implementation Planning Workshop or
Engagement Workshop. Stakeholder analysis is begun during the Bid Transition process, therefore review the documentation from Bid Transition, if available.
As project managers we are required not only to manage internal project members but also to ensure that the concerns of key stakeholders are addressed and that the
efforts of these stakeholders are aligned with the project's business objectives. Communication of project goals, progress, requirements and impacts is key to ensuring
that stakeholders are informed and aligned with project goals. Specifically, stakeholders need to be made aware of the status of issues and change requests,
adjustments to the project workplan, corrective actions and lessons learned. These communications should be made frequently and clearly and should be coordinated
with the Client's Organizational Change Management Strategy (OCHM.010) and later with the Implement focus area Organizational Change Management process.
Use a matrix with Influence (high to low scale) and Contribution (high to low scale) and placing the stakeholders in one of the four quadrants within a grid (See example
below). The Communication Plan can use the quadrants as a basis for the types of communications that need to be made.
Assess Stakeholder Concerns
It is important to identify the stakeholders concerns for the following reasons:
Concerns can be addressed proactively.
All stakeholders are vested in the project and not alienated.
Overall project risk is reduced.
The project can focus on satisfying the concerns of the most important stakeholders (see stakeholder prioritization below).
USE THE STAKEHOLDER LIBRARY
If there is an enterprise-level Stakeholder Library available (ENV.BA.015), then this is a good place to retrieve the stakeholder base concerns. Now review the project risk
register to see how any risk affects the identified concerns. For example, consider how the following affects identified concerns:
Which resources will be available and what skills do they have?
What budget is on hand?
What is the schedule?
Referring to historical stakeholder information related to your project or the enterprise can save time and flag risks, liabilities, or unresolved issues that can then be
prioritized and managed.
Prioritize Stakeholders
The purpose of the stakeholder prioritization is to determine which stakeholders (and their associated concerns/interests) may significantly influence the success of the
project. Therefore, the prioritization should have an influence on when and how to communicate with the stakeholders. Also, since resources, time and finances for
stakeholder analysis may be limited, the list of stakeholders to be interviewed must be prioritized. The type and scale of the project and the complexity of the concerns
should dictate how much time, at any stage of the project lifecycle, should be devoted to this task.
To assist with the stakeholder prioritization, stakeholders are analyzed by different attributes or criteria. These attributes aid in classifying stakeholders by relevance. They
should include project contribution and project influence at a minimum but can be extended depending on the organization's requirements.
ASSESS STAKEHOLDER CANDIDATES
Each stakeholder candidate is assesses against a list of predefined criteria to assist with stakeholder prioritization.
Project Contribution Score
Project Influence Score
Stakeholder Assessment Score (Multiply the Project Contribution Score by the Project Influence Score)
For each identified stakeholder, capture the three scores in a stakeholder analysis table.
EVALUATE STAKEHOLDER SCORE
After all stakeholders have been assessed, utilize the captured metrics to identify key stakeholders. Key stakeholders are those who can significantly influence or are
more importance to the success of the project. From the information captured, the most important stakeholders from a contribution and influence perspective can be
concluded.
By combining influence and importance metrics and using a grid diagram, stakeholders can be classified into different groups that will help identify assumptions and the
risks that need to be managed throughout the project lifecycle.
Primary Stakeholders
Primary stakeholders are stakeholders that have both significant influence over the project and contribute significant effort to the success of the project. These important
stakeholders have concerns, problems, needs and interests that are high priority and if they are not assisted effectively then the success of the project may be in
jeopardy.
Secondary Stakeholders
Secondary stakeholders should be addressed as much as possible subject to project time constraints.
Tertiary Stakeholders
Tertiary stakeholders are a low priority and should only be addressed if they require the same viewpoints as a primary or secondary stakeholder.
FINALIZE STAKEHOLDER PRIORITIZATION
The type and scale of the project and the complexity of the concerns dictates how many stakeholders concerns should be addressed. Use a stakeholder priority grid to
prioritize which project stakeholders to address.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Conduct session and document results. 85
Client Project Sponsor Participate in session and provide insight into the client. *
Client Project Manager Facilitate the development of the Project Stakeholder Analysis by providing insight in to the client. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Identified Project Stakeholders (BT.030) Use the stakeholders from this work product as the starting point of stakeholders to be analyzed.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CMM010_PROJECT_STAKEHOLDER_ANALYSIS.XLS
MS EXCEL
One technique for capturing and documenting the results of your stakeholder analysis is to use a 4-quadrant
Stakeholder Mapping matrix. This matrix categorizes stakeholders by their interest and influence, which
results in the following groupings and stakeholder management strategies:
High Interest/High Influence - High Interest/High Influence
Low Interest/High Influence - "Keep Satisfied"
High Interest/Low Influence - Keep Informed
Low Interest/Low Influence - Minimum Effort
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CMM.020 - DEVELOP PROJECT TEAM COMMUNICATION PLAN
Document a communications strategy for the project team (including the client responsibilities and tasks). The Project Team Communication Plan should include but is not
limited to:
Project kickoffs.
Written communications (including status reports) - executive, management, project team, and Oracle practice management.
Templates need to be provided - these must be performed consistently.
Distribution rules need to be established for all written communications.
Status Meetings - executive steering committee, management, and project team.
Meeting attendees need to be established for all meetings - required quorum also needs to be established.
Meeting standards need to be established for all meetings (e.g., agendas, minutes, action items).
Reporting Needs - what are the reporting needs identified for the project? What reports are expected, and at what frequency.
Plan and conduct a walk through of the planned project communications with the client, project team and Oracle practice management to gain understanding and
agreement for the project communications strategy. Whenever possible provide template an/or samples to convey the types and formats of planned communications.
The Project Team Communication Plan is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Project Team Communication Plan - The Project Team Communication Plan documents the overall communication strategy for the project team.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Determine overall
communication strategy.
Overview/Introduction Document the overall communication strategy for the project.
2 Review the Project
Stakeholder Analysis
(CMM.010).
Project Team
Communication
Matrix
Use the Project Stakeholder Analysis as the starting basis for this component. Update with any new
information.
3 Review all available means to
distribute information.
Delivery Channels Document what distribution channels are available to the client (e.g., e-mail, web conferencing, newsletters,
inter or intra net sites, etc.).
4 Review contractual and
procedural influences.
Required Reporting Document what reports are required for the project.
5 Review constraints and
assumptions to eliminate non-
essential requirements.
Constraints and
Assumptions
As an example - it is important to understand what budget you have to perform this task. Use of a web
developer or web conferencing may require funding in the project which you may or may not have.
6 Determine project meeting
schedules and other pertinent
meeting information.
Scheduled Meetings
(Calendar of Events)
Document when status meetings will be held, i.e., every Thursday at 9:00 AM or on some in frequent
calendar. Include purpose, attendees, location, remote access, etc.
7 Determine report distribution
frequency.
Calendar of Report
Distributions
Document when reports will be published, i.e., every Friday at end of business on the third Monday of the
month, etc.
8 Incorporate filing procedures. Project Archive
Structure
It is important to let everyone know where to file status reports and what the archive structure. This is
defined within the Document Management Plan in Configuration Management.
9 Determine Project Team
Communication Plan update
procedures.
Project Team
Communication Plan
Update Procedures
Document the procedures for updating the Project Team Communication Plan. This may include a review
process to determine if the update is necessary as well as whether any changes are needed to the Project
Team Communication Plan at a predefined time, i.e., each time the project manager reviews project status.
10 Obtain or create report
templates for all required
Report Templates
(for various reports)
Obtain or create templates for all required reports that will be used for the project. In general, oracle
procedures by region may recommend content for these reports and can be used as a base template.
reports. However, the client requirements may alter the template. Include a sample of each template as an appendix
to the plan.
11 Obtain key stakeholder
agreement and approval on
the Project Team
Communication Plan.
Approved Project
Team
Communication Plan
Obtain any necessary sign-off or Approval Certificate.
12 Make Project Team
Communication Plan available
to team members and client.
Project Team
Communication Plan
File the plan for easy reference.
Back to Top
APPROACH
The Project Team Communication Plan should address the reporting requirements of the project. As a first step this task should review the Project Stakeholder Analysis
(CMM.010). The team should then consider the importance of keeping each group informed based on influence and interest in the project, budgetary constraints and
delivery channels available to the team including such things as road shows, e-mail, newsletters, internet or intranet sites, presentations, web conferencing capabilities,
etc. Finally, it is up to this team to consider what contractual or procedural influences exist as to reporting requirements placed on the project.
The following reports are rather standard to most projects and should be considered for the project (other reports may also need to be considered):
Client Profile Sheet
Status Report
Steering Committee Report / Presentation
Financial Report
Project plans including the Project Management Plan and all of its components
The Project Team Communication Plan should discuss where these reports are stored / filed and indexed during the project. The structure is defined in the Document
Management Plan in Configuration Management. At a minimum, the Project Team Communication Plan must cover:
Operational Communication
Project Status Reporting: Team, Project, Steering, Others
Project Status Meetings: Team, Project, Steering, Others
Escalation Channels and Triggers
Use of the Project Repository
Formal Contractual Communication
Requirements in detailed accordance with signed contractual agreements (Notifications, Milestone Acceptances, Final Acceptances, etc., as specified by
contract)
Applicable elements of the Project Team Communication plan should be replicated as made relevant by any subcontractor/partner/other entities contractual
agreements.
Stakeholder Communication
Adoption and Change Management
Project meetings are scheduled in the Project Team Communications Plan. You should focus pursuing a clear understanding of efforts, status, and issues. You may want
to suggest that participants take meeting minutes on a rotating basis or arrange for the assignment of a recording secretary, enabling you to better concentrate on the
meeting. Circulation of notes to participants for final editing will help assure more complete and accurate publications.
A process needs to be defined to adjust the communications plan through out the project. As new stakeholders are added or removed from the project, when new
communications delivery channels become available or are lost or as changes to budgetary, contractual or procedural requirements are made, the Project Team
Communications Plan should be updated to reflect these changes to the project. This is a living breathing document and should not be written and then discarded as a
step completed.
While not highlighted within the Project Team Communication Plan, informal communications are key success factor in a project. The project team should incorporate
these informal communication channels in to the project:
Management by walking around is an excellent form of communication with team members. The focus of this day-to-day activity is to engage in brief informal
discussions to assess progress or problems and observe productivity. A good opening for these conversations is, Hows it going today?
Make time for informal group feedback. There are always external factors that impact project success. Ask what concerns the group has, what rumors they may
have heard. You may be able to provide direction on a stalled activity by removing misconceptions or ambiguities. Go to lunch, have a happy hour, gather around
the coffee pot.
Have an elevator speech on where you are in the project and what is coming up next
Results of the communications planning process include a document that defines:
Information collection and filing
Distribution structure detailing to whom information will flow
Description of information distributed, including format, content, and level of detail
Schedule defining when communications will be produced
Methods of communicating and updating changes to the plan
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Write Project Team Communication Plan. 85
Client Project Sponsor *
Client Project Manager Approve Project Team Communication Plan. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Communication Management requirements that should be taken into
consideration when developing the detailed Project Team Communication Plan.
Project Stakeholders
Analysis (CMM.010)
Use the Project Stakeholder Analysis as the starting basis for this component. Update with any new information.
Documentation
Management Plan
(CM.030)
The Documentation Management Plan documents a clear structure for document management that the project team can follow when creating
and storing project documents, the location where all documentation is stored, and the document version control procedures.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CMM020_PROJECT_TEAM_COMMUNICATION_PLAN.DOC MS WORD
CMM020_CLIENT_PROFILE_SHEET.DOC MS WORD
CMM020_STEERING_COMMITTEE_PRESENTATION.PPTX POWERPOINT
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CMM.030 - MANAGE PROJECT TEAM COMMUNICATION
In the Manage Project Team Communication task, you put into practice the reporting requirements, scheduled meetings and procedures documented in the Project Team
Communication Plan and manage communication. This task is ongoing throughout the Project Execution and Control phase.
Using the Project Team Communication Plan to manage is similar to all other areas of management in that you need to be prepared to evaluate and make changes to the
plan as the project progresses. The key areas to be addressed in managing communication are:
Compile data from various input sources to create the various communications.
Publish the communication in the various reports.
Conduct project meetings.
Meet the distribution schedule for each communication (report).
File the communications (reports) according to the Project Archive Structure.
Evaluate the effectiveness of the Project Team Communication Plan and adjust the plan as necessary.
ACTIVITY
PEC.ACT.MCOP Manage Communications and OCM Plans
Back to Top
WORK PRODUCT
Project Team Communication - Project Team Communication is the result of the execution of the Project Team Communication Plan. Communication is gathered,
reported, and distributed according to the Communication Plan.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Compile and gather data. None Individual reports, issue logs and financial data
should be gathered.
2 Complete and publish reports using the
templates and schedules detailed in the Project
Team Communication Plan.
Various Reports (Status Reports, Steering Committee Reports,
Financial Reports, and other key reports as defined in the Project
Team Communication Plan)
Write summary reports from the gathered data.
3 Conduct project meetings. Meeting Minutes Conduct scheduled meetings and take minutes
of key decisions.
4 Distribute reports. Various Published Reports Reports are made available or delivered to
stakeholders.
5 File reports. Updated Project Archives Place communications in the proper place in
the Project Archive as defined by the
Communication Plan.
6 Evaluate and adjust Project Team
Communication Plan.
Revised Project Team Communication Plan Gather feedback informally or formally on the
effectiveness of communications and adjust
the plan as necessary.
Back to Top
APPROACH
The project manager should review the Project Team Communication Plan and ensure that each required communication is occurring as planned or make adjustments to
the plan as required. In this respect, the project manager should ensure that such things as Status Reports, Steering Committee Reports and Financial Reports are
generated and distributed timely and that all reports are being properly filed.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
10
Project Manager Update Project Team Communication Plan. Publish summary reports, distribute and file. 65
Team Member Publish individual reports, distribute and file. 25
Client Project Sponsor *
Client Project Manager Approve changes to Project Team Communication Plan. Publish summary reports, distribute and file. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Team Communication
Plan (CMM.020)
The Project Team Communication Plan documents the overall communication strategy for the project team. Use the procedures
documented in the plan to manage project team communications.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CMM030_MEETING_MINUTES.DOC MS WORD
CMM030_WEEKLY_PROJECT_STATUS_REPORT_W_INST.DOC
CMM030_WEEKLY_PROJECT_STATUS_REPORT.DOC
MS WORD - These templates are the same. The first template includes instructions.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CMM.040 - DOCUMENT LESSONS LEARNED
At the start of Project Closure, Conduct a Lessons Learned session and document the findings. In many cases, this is viewed as the last step in the process. However, it
is recommended that this task occurs closely after the Go-Live date of the project and prior to the project team being redeployed to other opportunities. This is especially
key as it is often difficult to pull resources back together to hold this session once the team has begun to disperse.
While this task is placed squarely in the Project Closure phase of the project, this task can often be conducted at the end of a phase of the project and prior to the next
phase beginning. In this way, the project can use this task as a continuous improvement step within the overall project.
A lessons learned session is an important part of the project close-out process because it a primary method through which we learn and gather suggestions for
improvement. The output of the lessons learned session can be utilized as an input to planning the next project. The results of lessons learned sessions are important
because they add to the common understanding of what a good project is and how detrimental influences can be avoided.
Therefore, a Lessons Learned session is intended to:
Be an opportunity to review and document events that impacted success or failure of a project
Provide a basis for process improvements
Increase likelihood of success of future projects.
Project Managers should be cautious not to use the session as a finger pointing session, a blame session or a way to find excuses for failure.
ACTIVITY
PC.ACT.DLLAP Document Lessons Learned and Archive Project
Back to Top
WORK PRODUCT
Lessons Learned - The Lessons Learned documents what went well, what worked and what can be improved the next time a similar project is undertaken. It is generally
organized by process.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Conduct Lessons
Learned Session.
None Organize by process and document what worked well and where opportunities exist for
improvement.
2 Gather any
process-specific
Lessons Learned,
if available.
Various Process Lessons Learned (e.g.,
Scope Management Lessons Learned,
Work Management Lessons Learned,
etc.)
If any processes documented a process-specific Lessons Learned, incorporate it into the project
Lessons Learned.
3 Perform a "post-
engagement"
estimate.
Post-engagement Estimate This step includes completion of an estimating model based upon the actual characteristics of the
engagement that has just been completed. The completed estimate would then be used to
compare to the actuals of the project to assist in reviewing the accuracy of the estimating model(s).
4 Organize and
compile Lessons
Learned.
Lessons Learned Compile the Lessons Learned. Organize all the individual documents into one document. Add any
information to the appropriate process section. Add a structure (i.e., title page, contents, index,
etc.).
Back to Top
APPROACH
Gather all project team members to discuss what went well, what worked and what can be improved the next time a similar project is undertaken. Document the results.
As part of Project Closure, each process may have already documented a process-specific Lessons Learned. In that case, compile the various process-specific reports
into one project Lessons Learned. Add any additional comments to the appropriate process sections. Organize the Lessons Learned with a title page and contents.
The following are recommended topics for inclusion in the lessons learned document:
Provide advice/suggestions from your perspective on what you've learned, experienced and observed from an overall process and project management for your
implementation(s)
Include "things done well" that would be beneficial to future engagements
Include "opportunities for improvement" or things that you would add, change or delete if you had a chance to do it over again.
Elaborate as required to fully explain the lesson
Project Success
Project implementations are successful when they:
Are delivered on time
Are delivered within cost
Meet quality and functional requirements
Satisfy the customer, AND
Deliver the benefits as defined in the business case
Questions to be Considered when Completing Lessons Learned
Was the project successful?
Was it delivered on time?
Was it delivered within cost?
Did the work products meet quality and functional requirements?
Was the customer satisfied?
Did the project achieve the benefits as defined in the business case?
Existence and Effectiveness of Critical Success Factors
Sponsorship and Business Case
Was there a defined and compelling business case (e.g. R/A)?
Was the leadership involved in defining the business case?
Did the leadership fully understand, support, and buy-into the business case?
What things did the leadership do to support the project that was effective? Not effective?
What things should the leadership have done more of? less of?
List things done well in the area of sponsorship and business case.
List opportunities for improvement in this area.
Approved Project Plan
Was there an approved project plan before the project started?
Did the project plan define the what/how/when/who/cost of the project?
List things done well in the area of project planning.
List opportunities for improvement in this area.
Project Management
Was there sufficient and effective project management to guide the project?
Were there activities to support planning, activating, controlling and ending the project?
When changes occurred that would impact any of the measures of a success project (time, cost, quality, customer satisfaction, benefits), was there a change
order process to renegotiate the contract with the sponsors?
List things done well in the area of project management.
List opportunities for improvement in this area.
Execution of tasks
Were the tasks as defined in the work stream structure efficiently and effectively performed?
Were the tasks to be performed documented, standardized and repeatable?
Was there appropriate facilitation of the tasks that needed to be performed?
List things done well in the areas of task execution.
List opportunities for improvement in this area.
List lessons learned in the area of configurations, setups, etc.
Quality Assurance
Was there an effective process in place to assure the existence and quality of the work products?
List things done well in the area of quality assurance.
List opportunities for improvement in this area.
Issue Resolution
Was a process in place to quickly raise and resolve issues that were beyond the scope of the project team to resolve?
Was a process in place to quickly identify and resolve issues that were in the scope of the project team to resolve?
Were there any issues that were either not resolved or not resolved quickly enough that impacted the project schedule?
List things done well in the area of issue resolution.
List opportunities for improvement in this area.
People
Were there a sufficient number of people resources to successfully complete the project?
Was there a sufficient capability of people to successfully complete the project?
Was the personal safety, health and well being of people (stakeholders) appropriately attended to?
List things done well in the area of people.
List opportunities for improvement in this area
Support Processes
Was there an effective organization (team structures, inter-team processes, intra-team processes) in place?
Were there support processes in place to facilitate the work? (e.g. administration, etc.)
Were the tools sufficient to complete the work?
Were the facilities and physical work environment conducive to effective work and team processes?
Was the work environment conducive to teaming, cooperation and productivity, quality of life, etc.?
List things done well in the area of support processes.
List opportunities for improvement in this area.
Technical Infrastructure
Was a 24 x 7 in control and capable technical environment in place to support the work?
Where the instances available when needed?
List things done well in the area of technical infrastructure.
List opportunities for improvement in this area.
Change leadership and management
Were a business case, organization readiness assessment and stakeholder analysis effectively performed as key first steps toward defining a change plan?
Was there change plan to support the project implementation?
Did it address:
Opportunity realization and risk mitigation
Mobilization and alignment of leaders
Communication with stakeholders
Design and development of the future organization
Preparation and equipment of the workforce (training)
Were leadership and management change activities appropriately integrated into the project plan to enable project success?
Risk mitigation
Opportunity realization
Communication planning and execution
Leadership involvement
Future organization design
Training of key stakeholders
List things done well in the area of change leadership and management.
List opportunities for improvement in this area.
Back to Top
SUPPLEMENTAL GUIDANCE
SOA Engineering Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Engineering
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA
Engineering Planning Supplemental Guide.
SOA Modeling Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Modeling Planning
service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Modeling supplemental information, use the SOA Modeling
Planning Supplemental Guide.
SOA Governance Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Governance
Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Governance supplemental information, use the SOA
Governance Planning Supplemental Guide.
SOA Reference Architecture Planning
This task has supplemental guidance that should be considered if you are performing an engagement using the Service-Oriented Architecture (SOA) Reference
Architecture Planning service offering. Use the following to access the task-specific supplemental guidance. To access all SOA Reference Architecture supplemental
information, use the SOA Reference Architecture Planning Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
10
Project Manager Prepare Lessons Learned Report. 65
Team Members Participate and share views on what worked and what could be improved. 25
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CMM040_LESSONS_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CMM.050 - TURN OVER PROJECT DOCUMENTATION
As part of Project Closure, organize and turn over all project documentation.
Provide client with all project documentation, work products and other relevant information. Also provide the client with a checklist of these items.
Ensure compliance with the implementing organizations (for example, Oracle) responsibility to protect client confidential information.
Finalize archive of all project work products (hardcopy and disks) in compliance with the implementing organization Document Retention Policy.
ACTIVITY
PC.ACT.DLLAP Document Lessons Learned and Archive Project
Back to Top
WORK PRODUCT
Project Archives - The Project Archives is all the project documentation organized and stored to media, turned over to the client and retained per the implementing
organization's Document Retention Policy.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Organize and provide project documentation, work
products and other information to client.
Client Project Archives All project documentation, work products and other information are organized and
stored to media (hardcopy, disk) and turned over to the client.
2 Comply with Code of Conduct regarding confidential
information.
Protected Client
Confidential
Information

3 Finalize archive of project work products for 48
months post warranty.
Project Archives All project work product are are organized and stored to media (hardcopy, disk) and
retained per Document Retention Policy.
Back to Top
APPROACH
The project manager should walk the client through the final structure and agree that archives are now the complete responsibility of the client. The implementing
organization records should also be organized and retained.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Turn over archives to client. 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CMM.060 - SUBMIT FINAL REPORTS
In this task, you prepare any necessary Final Reports for the key sponsors. These reports include but are not limited to the following:
Project Engagement Summary
Final Project Status Report
Final Financial Report.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Final Reports - The Final Reports are prepared at the end of the project for the key sponsors.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Gather information and prepare Project
Engagement Summary
Project
Engagement
Summary
Complete report.
2 Prepare Final Project Status Report. Final Project Status
Report
Complete report.
3 Prepare Financial Report. Final Financial
Report
Complete report.
4 Prepare any other reports, as necessary Various Final
Reports
Complete reports.
5 Review Final Reports with key sponsors and
agree on project closure.
Sign-Off Obtain any sign-off or Approval Certificate. Ask the key sponsors to sign-off that they agree
that the project is closed and obtain any feedback.
Back to Top
APPROACH
Prepare a Project Engagement Summary for the key sponsors at the conclusion of the project. This should summarize, at a minimum:
Final scope including approved change orders
Change orders that were requested but not approved
Financial performance (or earned value analysis)
Schedule performance (or earned value analysis)
Project accomplishments
Any open issues, risks or problems that need to be addressed by the key sponsors moving forward
Additional areas of opportunities moving forward (license, consulting, and support)
Prepare final Project Status Report and Financial Report.
Prepare any additional final reports, as necessary.
Review Final Reports with key sponsors.
Agree on project closure.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Prepare Final Reports. 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
All Prior Project Reports (Project Archives)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CMM060_PROJECT_CLOSURE.DOC MS WORD
CMM060_END_REPORT.DOC MS WORD
CMM060_ENGAGEMENT_SUMMARY.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[QM] QUALITY MANAGEMENT
"Project Quality Management includes all the activities of the performing organization that determine the quality policies, objectives, and responsibilities so that the project
will satisfy the needs for which it was undertaken. It implements the quality management system through the policy, procedures, and processes of quality planning,
quality assurance, and quality control, with continuous process improvement activities, conducted throughout..." (from the Project Management Institute's A Guide to the
Project Management Body of Knowledge Third Edition). The Quality Management process is broken down in three (sub) processes:
Quality Planning - identifying which quality standards are relevant to the project and determining how to satisfy them
Quality Control - monitoring specific project results to determine whether they comply with the relevant quality standards
Quality Assurance - executing the systematic quality activities to determine if the quality processes are being followed and whether they are satisfying the projects
quality needs
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During Project Start Up, the project manager must define, in the Quality Management Plan, the strategies, standards, and procedures in the areas of Quality Planning,
Control, Assurance as well as Process Improvement. The project manager must also develop the overall governing process and establish control and reporting
mechanisms to ensure that the quality of the project implementation process and work products meet stipulated standards.
Project Execution and Control Phase
Throughout the Execution and Control phase of the project, the project manager monitors the Quality Control as set forth in the Quality Control and Reporting Process
documented in Project Start Up to ensure that work products are properly reviewed and meet specifications prior to presentation to the client. The project manager must
also assess whether all Quality Management (sub)processes are functioning according to plan and, if not, take corrective action. The project manager keeps the
stakeholders informed on key aspects of the project. Product problems are not managed as part of the Quality Management process, they are tracked via the Issue and
Problem Management process for follow up and resolution.
Prior to go-live, comprehensive reviews (internal and external) must be undertaken to confirm that the project results are in compliance with contractual obligations, and
that the requirements and objectives of the Quality Management Plan have been achieved.
Project Closure Phase
A comprehensive Post-Production Quality Review(s) must be undertaken to confirm that the project has been conducted according to the Quality Management Plan and
that all activity and results were in compliance with contractual obligations, and that the objectives of the Quality Management Plan have been achieved. Instances of
project commitments, requirements, and objectives not achieved must be documented and communicated to key stakeholders.
Quality Manager
Some projects have a dedicated quality manager. If so, the quality manager, with guidance from the project manager, plans and prescribes all matters affecting quality of
a project.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS QM.010 Develop Quality Management Plan Quality Management Plan Y Core
PS QM.020 Develop and Document Quality Control and Reporting Process Quality Control and Reporting Process Y Core
Project Execution and Control
PEC QM.030 Develop Project Team Quality Management Orientation Project Team Quality Management Orientation Core
PEC QM.040 Manage Quality Control Quality Control Y Core
PEC QM.050 Perform Quality Assurance Managed Quality Assurance Y Core
Project Closure
PC QM.060 Conduct Post-Production Quality Review Post-Production Quality Review Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager

Client (User)
CPS Client
Project
Sponsor

Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
QM.010 - DEVELOP QUALITY MANAGEMENT PLAN
Today, customers place increasing importance on the role of quality in the goods and services they purchase. Quality management has become a proactive, process-
driven practice that is critical to successful project management. It is the key element in assuring that all of the projects requirements are satisfied.
The goal of this task is to establish the quality objectives for the project work products as well as the project delivery process. This plan should describe the quality
processes, standards and procedures that will be used during the project implementation in order to facilitate the stakeholders involved in the product acceptance to
verify its conformance to stipulated requirements. This information is then documented in the Quality Management Plan. The Quality Management Plan is a key
component of the Project Management Plan. In keeping with the organization of the Quality Management process, the Quality Management Plan has three major
components:
Quality Planning Process
Quality Assurance Process
Quality Control Process
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Quality Management Plan - The Quality Management Plan documents the quality processes, standards and procedures that will be used during the project
implementation in order to facilitate the stakeholders involved in the product acceptance to verify its conformance to stipulated requirements.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Establish the Quality Planning Process. Quality Planning Process Document the Quality Planning Process. Include the following
sections:
Purpose
Scope
Client Culture
Definitions
Process
Tools and Techniques
Standards
Procedures
Quality Activity Schedule
2 Establish the Quality Assurance Process. Quality Assurance Process Document the Quality Assurance Process. Include the
following sections:
Purpose
Scope
Process
Tools and Techniques
Quality Assurance Questions
3 Establish the Quality Control Process. Quality Control Process
- Purpose
- Scope
- Tools and techniques
Document the Quality Control Process. Include the following
sections:
Purpose
Scope
Tools and Techniques
4 Obtain key stakeholder agreement and approval on the Quality Approved Quality Obtain any necessary sign-off or Approval Certificate.
Management Plan. Management Plan
Back to Top
APPROACH
Quality Planning Process
Quality Planning is the process of identifying which quality standards are relevant to the project and determining how to satisfy them. Document the decisions and
conclusions from the Quality Planning Process in the Quality Planning Process component of the Quality Management Plan. The Quality Planning Process should
specifiy the plan to establish, monitor and ensure quality objectives for project deliverables and work products as well as the project delivery process. Use the following
information to complete the sections of the Quality Planning Process component.
Client Culture regarding Quality Management: Identify the client's quality management requirements in the Quality Management Plan.
Definition
Include generally accepted definitions that could be explicit in the document in order to facilitated the overall understanding of quality management. Consider including the
following:
Quality of product is the conformance to requirements to user needs and expectations.
Quality of delivery process is the conformance to the process established to conduct the project.
Quality of specification is the conformance to specifications of requirements or specification of delivery process. Specifications could be understood as a
translation of requirements using the project standards established in the execution method (i.e. standard that define how to write a functional specification) or to
perform the project management processes in the Project Management Method (i.e. Project Management Framework that establish all Project Management
Process)
Quality Review is a type of assessment undertaken to ensure the suitable, adequacy, effectiveness, and efficiency of the subject matter to achieve established
objectives. There are many types of quality reviews that could be used as a tool to perform a quality assurance or a quality control activities.
Tools and Techniques
Describe the tools and techniques that the project will use. It's not appropriate to include techniques that you do not plan to use.
Start by obtaining the standards and procedures from the Project Management Framework and from the execution method, such as the testing strategy and testing
documents standards is a technique to select those that apply to the current project.
The output of Quality Planning is this document, the quality management plan with all standards, procedures and checklists that should be used to the further quality
process, as well as the master schedule for the quality activities and the updated project plan with the quality baseline.
Standards
In this section, identify which standards will be used by the quality activities during the project.
The specification of each Project Management Method delivery process are described as a standard in the Project Management Framework (refer to BT.070 Project
Management Framework) and the specification of each execution method delivery process are described as a standard to perform the correspondent tasks. Therefore,
OUM Manage contains the standards that should be applied to perform the quality activities related to the project management activity and the execution method
contains the standards that should be used to perform the quality activities related to product that should be delivered.
For Application Implementation projects consider the standards defined by the Oracle On Demand group in the areas of Configuration, Extension, Modifications,
Localization and Interface development and deployment.
Some of the standards are:
BT.070 Project Management Framework
Documentation Control Standards
Configuration, Extension, Modifications, Localization and Interface Standards from Oracle On Demand
Procedures
Identify which procedures will be used to perform quality activities during the project and reference where it is described. Typical procedures are:
QM.020 Quality Control and Reporting Process
Document Control and Approval Procedure
Production Assessment Review
Performance Compliance
Quality Activity Schedule: Identify the main quality activities that will be performed during the project. The description should include its classification area (Quality
Planning, Quality Assurance, or Quality Control), the phase of the project where the quality activity will be performed, who is responsible for performing it, the work
product that will be produced at the end of the quality activity.
Describe the tool, technique, procedure and standard that applies to the planned quality activity, in the quality control process definition.
The detailed tasks and related activities should be managed in the Work Management process.
The table below shows an example of a quality activity schedule:
Quality Activity Quality Process Phase Who Milestone Work Product
Develop Quality Management Plan Quality Plan Start Up Project Manager QM.010 Quality Management Plan
Planning Review Quality Assurance Start Up External Quality Manager
Work Product Review for Definition Phase Quality Control Definition Project Manager / SME / Client
Quality Assurance Process
Quality Assurance is applying the planned, systematic quality activities and any ongoing processes to ensure that the project employs all delivery processes needed to
meet requirements. Quality assurance is a periodic or ongoing evaluation of the projects quality process with the objective of deciding whether the projects work
products are meeting the stated or implied needs of the project. A secondary purpose is to assure the stakeholders that the system is producing appropriate and
acceptable work products and that the sum of the work products will equal the projects objectives. During this task, you document the quality activities and any ongoing
process that will be used during the Perform Quality Assurance task (QM.050) in the Quality Assurance Process component of the Quality Management Plan.
Quality Control Process
Quality Control is the process of monitoring specific project results to determine whether they comply with relevant quality standards and identifying ways to eliminate
causes of unsatisfactory results. During this task, you document at a high-level the purpose, scope and tools and techniques for the Quality Control Process. The
following task, Develop and Document Quality Control and Reporting Process (QM.020) describes in detail the Quality Control Process and tools that will be used in the
project.
Quality reviews, quality control tools, inspection, defect repair review, and testing strategies from the execution method are common tools used to perform quality control.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Develop the Quality Management Plan. Depending on your project, you may have a designated quality manager in this role
that reports to the project manager.
85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Quality Management requirements that should be taken into consideration
when developing the detailed Quality Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM010_QUALITY_MANAGEMENT_PLAN.DOC MS WORD
QM010_QUALITY_MANAGEMENT_PROCEDURES.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
QM.020 - DEVELOP AND DOCUMENT QUALITY CONTROL AND
REPORTING PROCESS
Quality Control is the process of monitoring specific project results to determine whether they comply with relevant quality standards and identifying ways to eliminate
causes of unsatisfactory results. During the previous task, Develop Quality Management Plan (QM.010), you documented at a high-level the purpose, scope and tools
and techniques for the Quality Control Process. In this task, you develop and document a Quality Control and Reporting Process, using the information in the Quality
Management Plan as a starting point. Specifically, during this task you identify what key project elements require monitoring and control and their associated required
characteristics and performance criteria that must be monitored, analyzed, evaluated, and controlled. Document how they will be monitored and measured, and how the
results will be communicated to project stakeholders.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Quality Control and Reporting Process - The Quality Control and Reporting Process identifies and documents the following:
Key Project Elements that require monitoring and control and the associated Required Characteristics / Performance Criteria
Processes to:
Identify and review Key Project Elements and document actual achievement versus Required Characteristics / Performance Criteria.
Compare the actual achievement versus the Required Characteristics / Performance Criteria, analyze the results, and determine quality performance.
Assemble and communicate the quality performance results (management information) to all key stakeholders.
Assemble and communicate process improvement feedback (issues/problems, remedial action recommendations) to the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Determine the key project elements that require
monitoring and control and identify/establish the
associated required characteristics /
performance criteria.
Key Project
Elements and
Performance
Criteria
This component provides a list of all the key project elements that require monitoring and
control along with the required characteristics and performance criteria for each. A
description of acceptance criteria for project work products and the project overall (usually
spelled out in the contract).
2 Develop and document processes to review key
project elements, compare the actual
achievement versus the required characteristics /
performance criteria.
Comparison of
Actual
Achievement vs
Performance
Criteria
Document processes to review key project elements and document actual achievement
versus Required Characteristics / Performance Criteria and compare them to what was
actually achieved.
Include a list of the Quality Control roles and responsibilities.
Describe how the quality of the project processes is to be determined (project reviews) and
how the quality of project work products is to be determined (work product reviews).
Document processes to assess the effectiveness of the testing plan.
3 Analyze and communicate the results. Results Analysis
and
Communication
Document processes to:
Analyze the results, and evaluate performance
Communicate the quality performance to stakeholders
Communicate process improvement feedback to the project.
4 Obtain or create Quantity Control Reports Quality Control
Checklist
Quality Control
Performance
Notification
Obtain or create any necessary Quality Control forms.
Quality Control
Process
Improvement
Feedback
Notification
5 Obtain key stakeholder agreement and approval
on the Quality Control and Reporting Process
Approved Quality
Control and
Reporting
Process
Obtain any necessary sign-off or Approval Certificate.
Back to Top
APPROACH
Quality Control vs Quality Assurance
It is important to maintain the distinction between Quality Control (inspection) and Quality Assurance (management).
A Quality Control process can be as simple as verifying that a report was spell checked before submitting it to the customer. It can be as complex as a multi-person code
walk through. The project manager needs to decide how much detail is needed and how intricate the process will be. The goal is to routinely examine work items (work
products, intermediate products, and services) during their creation/delivery and ensure that they conform to project standards.
Quality assurance is the process of looking at the sum total of the quality activities in the project and assessing whether they are achieving the quality objectives laid out in
the Quality Management Plan.
Activities associated with the Quality Control Process are:
Determine and document the Key Project Elements that require monitoring and control and the associated Required Characteristics / Performance Criteria.
Identify the acceptance criteria for project work products and the project overall (usually spelled out in the contract).
Specify quality roles and responsibilities.
Describe how the quality of the project processes is to be determined (project reviews) and how the quality of project work products is to be determined (work
product reviews).
Develop and document processes to systematically examine the Key Project Elements and document actual achievement versus the Required Characteristics /
Performance Criteria.
Describe the testing plan, how it will be developed, reviewed with the client, and approved.
Review the actual achievement versus the Required Characteristics / Performance Criteria, analyze the results, and determine quality performance.
Communicate the quality performance (management information) to all key stakeholders.
Assemble and communicate process improvement feedback (issues/problems, remedial action recommendations) to the project.
Quality reviews, quality control tools, inspection, defect repair review, and testing strategies from the execution method are common tools used to perform quality control.
Definition: Required Characteristics / Performance Criteria: are properties that a Key Project Element must have in order to meet management expectations and/or
effectively fulfill an intended role within the project. The are generally specified as follows:
conformance to specified requirements (contract, procedures, regulations, etc.)
achievement of specified results (reject levels, cycle times, etc)
attainment of specified expectations (profitability, critical success factors, etc.)
Identifying Key Project Elements
Key Project Elements: are aspects of the project, that in the judgment of management, are significant enough to influence success or failure and therefore require
monitoring and control.
The are generally identified from the following areas:
Contractual Obligations
Statutory Regulations
Internal/External Organizational Standards, Requirements, and Expectations
Project Processes, Procedures, Activities, Test Results, Outcomes, and Accomplishments
Key project elements that require monitoring and control must be identified from a variety of sources. They must be identified and assembled in a consolidated list. The
obvious focus is on those elements that are relevant and significant to the success or failure of the project, i.e. those elements that influence:
Contractual Compliance
Statutory Compliance
Client Satisfaction
Oracle Expectation Achievement
Examples of a more detailed breakdown are:
Contractual Requirements
work products
Service Level Standards
Roles and responsibilities
Assumptions
Critical Success Factors
Performance Objectives
Statutory regulations
National, Regional, Local
OC and Client Standard Operating Procedures (Project Management Plan)
Corporate, Regional, Business Unit, Practice
Bid Transition
Scope Management
Financial Management
Work Management
Quality Management
Risk Management
Issue/Problem Management
Staff Management
Communication Management
Configuration Management
Infrastructure Management
Procurement Management
Organizational Change Management
Industry Leading Practices
Mutually Established Project Conventions
Client Specifications and Expectations
Oracle Consulting Specifications and Expectations
Test Results
If the customer has a formal quality policy in place, look for any required processes that involve documentation of test or inspection activities, or a feedback and corrective
action cycle. Specific activities, such as design standards or reporting requirements that are relevant to the project may also be mentioned in the policy. Everything in
the quality policy that applies to the project is a quality need and must be included in the Quality Control and Reporting Process.
The Project Management Plan, as the guideline for all project activities, is an important factor in determining quality needs. The project critical success factors will also
help to define quality needs. Focus on each success factor; identify the appropriate standards and quality control processes that will ensure that each one will be
achieved. The projects service levels, availability, and performance objectives are other elements for which quality needs can be identified.
Determine Required Characteristics / Performance Criteria (Quality Needs); Review,
Document, and Compare the Actual Achievements
Required Characteristics / Performance Criteria are properties that key project elements must have in order to meet management expectations and/or effectively fulfill an
intended role within the project. A shorter description for this is quality need.
Examples of key project elements and corresponding required characteristics / performance criteria (quality needs) follow:
Key Project Element Required Characteristic / Performance Criteria (Quality Needs)
1. Configuration Management Plan
Follow recommended format.
Complete and approved by plan date.
Content compliant with recommended by procedure.
2. Run Payroll Test (Test Plan Element)
Meet specifications defined in the Test Plan.
Examples of Actual Achievement reporting follow:
Key Project Element Required Characteristic / Performance Criteria (Quality Needs) Actual Achievement
1. Configuration Management Plan
Follow recommended format. Compliant
Complete and approved by plan date. Not Compliant (2 weeks late)
Content compliant with recommended by procedure. Partially Compliant
2. Run Payroll Test (Test Plan Element)
Meet specifications defined in the Test Plan. Compliant with Specifications
Execution procedures must be established to define:
Monitoring responsibilities and approach
Data collection formats, frequencies and techniques
Actual achievement reporting conventions
Distribution lists
Process maintenance
Examples of techniques to provide quality control are:
Self-certification (individual work products)
Peer review (individual work products)
Independent review (overall project; work product sets)
Management review (overall project; work product sets)
External review (overall project; work product sets)
Examples of roles involved in quality control are:
Quality Manager - oversees preparation and review of project quality plans and assignments.
Quality Reviewer(s) - responsible for conducting regular project/process reviews
Quality Reviewer(s) - responsible for conducting quality reviews of project work products
Examples of external reviews/audits (taken from NAC standards) are:
Startup Tollgate (STG) Remote review (0.5 day). Provide an assessment and review of key startup activities and documentation to confirm successful project
start. A Startup Tollgate internal Report will be provided to PM and Practice Management at the conclusion of the Startup Review which will document and
communicate satisfactory Startup compliance status.
Delivery Assurance Review (DLR) Onsite or Offsite review (2 days). Provide comprehensive quality assessment that focuses on project performance,
governance and risk components associated with project delivery. After the DLR is completed, a DLR internal Initial Report will be distributed to PM and Practice
Management which will provide an evaluation of overall status, compliance (specific determination of compliant and non compliant items), follow up actions and
expected completion dates (within two weeks). A formal follow up process will be conducted that will determine the final status of the project and open items. A
DLR internal Final Report will be issued. Any remaining open actions at that time will be sent to the owning Portfolio Director for immediate follow up and
resolution.
Project Readiness Review (PRR) Onsite or offsite review (2 days). Provide a thorough review of go live project activities to validate overall readiness, identify
and prevent problems subsequent to production cut over. Similar to the DLR, a PRR An internal report will be distributed by QMG to PM and Practice
Management which will provide an evaluation of overall status, compliance (specific determination of compliant and non compliant items) and follow up actions.
Due to the timing and nature of the review, a strong emphasis is placed on quick and immediate resolution of open items prior to go live.
Examples of external approaches are:
Walk through: (individual or group) is a review whereby the reviewer(s) step through a work product to check for errors, inconsistencies, incompleteness, etc. The
findings and recommended actions resulting from the Walk through must be documented. Group Although should be coordinated by a designated leader.
Inspection: has the same purpose but is a more formal version of a Walk through. Formal roles are assigned to reviewers. These roles are:
Moderator (review lead)
Author (of the work product being reviewed)
Reader (reads out the part currently being reviewed)
Recorder (documents findings)
One or more reviewers who may also be role-playing (e.g., the customer view, the Oracle technical view, Oracle PM view, etc.).
Inspection reviews are extremely thorough since role-playing ensures that the work product is evaluated from many different angles and there is a great deal of
preparation before the Inspection itself. It is therefore the most expensive type of review to run, and should be used when appropriate (e.g., for end of phase work
products, for mission-critical work products).
Technical Review: focuses not just on looking for errors and incompleteness (as is the purpose of any review), but evaluates the technical aspects of a work
product e.g., elegance of code, functionality, etc. A Technical Design Review is a special type of Technical Review. A Technical Review is usually conducted as
part of a Walk through. or an inspection.
A key project element is the degree of self-sufficiency attained by the client organization prior to OC disengagement:
A possible quality control approach is to develop a knowledge sharing scorecard to evaluate the following sub-elements:
How self-sufficient is the customer?
What missing skills can additional training fill in?
What operational skills do they need to develop before they can run the system themselves?
Have you conducted dry runs when customers perform all of the processes to find out what knowledge gaps they have?
Start with a list of post-implementation responsibilities and related skills. Define the knowledge needed to carry out those duties independently. Identify the earliest and
latest point in the project where those skills could be transferred; then set the optimal time for the transfer. The optimal time is when the bulk of testing is complete and
further changes to the system will be minimal. Add checkpoints to your project plan to ensure that knowledge sharing is occurring.
Analysis of the results and corrective feedback could be used as a basis to develop a remedial training program.
Identify specific skills for each client team member to acquire, (that is, a team member might need to know Oracle Reports but not Java).
Ensure all client core team members receive appropriate Oracle classroom training.
Provide each person with an Oracle coach who has mastered the skill.
Identify how skill acquisition will be demonstrated (that is, complete all company setup for a new business unit).
Establish timeframe's for skill acquisition.
Establish knowledge sharing goals early in the project, then communicate and monitor them throughout the implementation. Create and publish a knowledge sharing plan
that identifies: the knowledge to be transferred, who will teach it, the specific resources to be taught, and the timeframe it will occur.
Analyze the Results and Communicate Quality Performance
In the end, actual achievement must be examined and compared to the required characteristics / performance criteria (quality needs) to determine results and evaluate
quality performance. But before communicating any results, determine the responsibility, frequency, format, and distribution for communicating quality performance in
management terms to all key stakeholders. In addition the PM will assemble and communicate process improvement feedback (issues, problems, and remedial action
recommendations) to the project team.
Management information and feedback reporting procedures must be established to define:
Generation Responsibilities
Formats and Content
Frequencies
Distribution Lists
Process Maintenance
Quality Review Reports
Test Results
Types of reporting tools and techniques frequently utilized are:
Cause and Effect Diagram
Control Chart
Flow Chart
Histogram
Pareto Chart
Run Chart
Scatter Diagram
Statistical Sampling
Inspection
Defect Repair Review
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Determine the Key Project Elements that require monitoring and control and identify/establish the associated Required
Characteristics / Performance Criteria. Develop, document, and execute processes to review Key Project Elements, compare
the actual achievement versus the Required Characteristics / Performance Criteria, analyze and communicate the results.
Assign and make sure regular project/process reviews are conducted.
Depending on your project, you may have a designated quality manager in this role that reports to the project manager. If so,
the quality manager would develop, document, and execute processes to review Key Project Elements, compare the actual
achievement versus the Required Characteristics / Performance Criteria, analyze and communicate the results. The
designated quality manager would also assign and make sure regular project/process reviews are conducted.
85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Quality Management Plan (QM.010) Use the processes defined in the Quality Management Plan to develop the Quality Control and Reporting Process.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM020_QUALITY_CONTROL_REPORTING_PROCESS.DOC MS WORD
QM020_QUALITY_CONTROL_CHECKLIST.DOC MS WORD
QM020_QUALITY_REVIEW_REPORT.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
QM.030 - CONDUCT PROJECT TEAM QUALITY MANAGEMENT
ORIENTATION
In the Project Start Up phase, the project manager must formally assemble the team to communicate the key tenets of the Quality Management Process, set the
appropriate expectations for the team, and thoroughly discuss quality management concepts. This activity can be conducted as a separate session or as part of a larger
meeting (for example, as part of an overall Project Kickoff).
ACTIVITY
PEC.ACT.OMT Orient and Manage Team
Back to Top
WORK PRODUCT
Project Team Quality Management Orientation - The Project Team Quality Management Orientation consists of project team that has attended a quality management
orientation and is aware of the key tenets of the Quality Management process for the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Develop Quality Management orientation presentation. Team Quality Management
Orientation Presentation
The Presentation explains key tenets of the Project Quality
Management process for the project:
What is quality on this project?
Quality milestones
Key aspects of the Quality Management Plan
Quality roles & responsibilities
2 Schedule orientation meeting or schedule presentation
during Project Kickoff.

Back to Top
APPROACH
The project manager is the leader and primary role model when it comes to quality. Every time he/she mentions quality, it communicates that quality merits a position of
high regard. If he talks about schedule and deadlines more than quality, the team will infer that he wants the work done on time regardless of the quality levels. This is an
impression that the project manager does not want to encourage. Remember, that the goal is ensure that quality is built in and not inspected in.
The project manager must establish that quality work products are an essential part of the project, and continually strive to build a project team culture in which team
members (Oracle, Client and third party) embrace the idea that every every team member contributes to overall project quality in everything that they do.
Use the opportunity to set expectations around quality in a formal team setting.
The orientation should cover topics such as:
Project Quality Scope - what quality on this project includes and what it does not include (e.g., It does not include gold plating and may not include certain types of
testing or documentation.)
Quality Milestones on the Project
Key Aspects of the Quality Management Plan
Purpose
Scope
Definitions
Process (Planning, Assurance, and Control)
Tools and techniques
Standards
Procedures
Master Schedule Plan
Project Team Quality Roles and Responsibilities
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager
Develop the Project Team Quality Management Orientation presentation and serve as the lead role model for project quality.
Depending on your project, you may have a designated quality manager in this role that reports to the project manager. If so,
the quality manager would then develop the Project Team Quality Management Orientation presentation and serve as the lead
role model for project quality.
85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Quality Management Plan (QM.010)
Quality Control and Reporting Process (QM.020)
Educate the team on the processes defined in these work products.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM030_PROJECT_TEAM_QUALITY_MANAGEMENT_ORIENTATION.PPTX POWERPOINT
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
QM.040 - MANAGE QUALITY CONTROL
The goal of quality control is to improve the likelihood of project success by systematically examining pre-determined key elements during project execution to ensure that
they are conforming to established standards.
In the Manage Quality Control task, you execute the Quality Control and Reporting Process (QM.020), which consists of the following steps:
Review Key Project Elements, and compare the actual achievement versus the Required Characteristics / Performance Criteria.
Analyze the results, and evaluate performance.
Review Reports
Test Results
Communicate the quality performance (management information) to all key stakeholders.
Responsibility, frequency, format , distribution
Assemble and communicate process improvement feedback (issues/problems, remedial action recommendations) to the project. Integrate with:
Test Process
Issue and Problem Management Process
This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MPQ Manage Project Quality
Back to Top
WORK PRODUCT
Quality Control - Quality Control is the execution of the Quality Control and Reporting Process.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Periodically evaluate all key project elements and
capture a snapshot of whether or not they meet
acceptance criteria.
Updated Quality Control
Checklist
A listing of key project elements and corresponding Required Characteristics /
Performance Criteria. The activity consists of indicating whether or not the the criteria
have been met.
2 Analyze the results of the key project element
review.
Updated Quality Control
Checklist
Once again the Quality Control Checklist is updated with the summarized and
categorized results of the key element review indicating which elements are compliant
/non-compliant with the specified criteria.
3 Communicate the quality performance
(management information) to all key
stakeholders.
Quality Control
Performance
Notification
E-mail notifications directed to designated project stakeholders with a summarized
checklist attached communicating results of the Quality Control Review for their
respective areas of interest.
4 Assemble and communicate process
improvement feedback to the project.
Quality Control Process
Improvement Feedback
Notification
Assemble and communicate process improvement feedback (remedial action
recommendations) to the project. Interface with the following processes:
Testing
Issue and /Problem Management
Quality Management
Back to Top
APPROACH
The Project Manager is ultimately responsible for the quality of the overall delivery and must therefore ensure that the quality process is being adhered to during the work
execution phase. This usually best done through sample reviews either by the project manager or and appointed, trusted reviewer. When resources are under pressure,
quality is often the first casualty. The effort to resolve quality issues late in a project usually far exceeds the effort to achieve the required quality initially.
The inputs to this task are the Quality Management Plan, Quality Control and Reporting Process, quality metrics, quality checklists, testing scripts (with expected results)
from the execution method.
The primary output of this task is the defect identification report. In addition, the defects must be analyzed to determine collectively whether their underlying causes
stemmed from a common source or whether their causes were unrelated. In quality parlance, were they common cause or special cause defects? Understanding the
source of your defects goes a long way toward helping you prevent future defects.
Quality Management activities include verifying conformance to standards, identifying/eliminating problem causes, and monitoring compliance with the quality control
processes. Responsibility for those activities should be delegated to the lowest team member that can successfully execute the process. For example: if programmers
can check each other's work, they should. If consultants or team leads can check procedure documents for completeness and format, the project manager should not do
it. The project manager should avoid direct involvement in most quality control activities except for those work products that have a payment milestone associated with
them.
A quality management process can be as simple as verifying that a report is spell checked before submitting it to the client. It can be as complex as a multi-person code
walk through. The project manager needs to decide how much detail is needed and how intricate the process will be. The possibilities for quality management processes
are infinite. They are intended to answer the questions:
Whether or not all of the control processes are being followed
Whether or not the processes are achieving the objective (the quality need)
Quality Management execution processes typically fall into one of the following categories:
Self-certification: The person who did the work signs off on a checklist
Peer review: The people who perform the same role on the team review the work
Independent review: Someone from outside the producing team reviews the work
Management review: The person who does the work has their supervisor review it
External audit: Someone from outside the project inspects the work
Each quality process category provides a different level of certainty that the quality standards were met. Choose a category appropriate to the level of importance that
the work being inspected has. Each key project element might have its own review process, but the basic approach is similar:
Review the work product against the specification
Identify defects (either design flaws or problems with the work product)
Summarize and communicate the results to the relevant stakeholders
Provide corrective feedback and remedial recommendations to address outcome defects and processes
Ensure that critical project processes and activities receive priority attention:
Work products must be presented for review and acceptance with the client in a walk-through fashion. That is, do NOT just deliver documents to the client with an
acceptance certificate attached.
Answer any questions/issues on the spot
Make sure to clearly explain all significant details of the work product to the client.
Ask for signature/closure during the walk through
Ensure that all work products requiring client review are physically signed off by client
Acceptance Certificates for fixed price projects must be signed by the client and submitted to finance, operations, and contracts for processing according to the contract
payment milestone schedule.
Testing Process must adequately address all conditions related to overall system acceptance.
Coding Standards Code Review Process should be established and published to the project team using the Project Documentation Library.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Responsible for managing and/or delegating responsibility for the development and execution of the project Quality
Management process. Responsible for the results and proper functioning. Depending on your project, you may have a
designated quality manager in this role that reports to the project manager.
85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Quality Management Plan (QM.010)
Quality Control and Reporting Process (QM.020)
These work products document the plan and processes for managing quality during the project.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
Managing an OUM Project using Scrum Use this technique for guidance on how Scrum affects Quality Management.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM040_REVIEW_COMMENTS_LIST.DOC MS WORD
QM040_REVIEW_LEADER_FORM.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
QM.050 - PERFORM QUALITY ASSURANCE
Quality Assurance is applying the planned, systematic quality activities and any ongoing processes documented in the Quality Management Plan to ensure that the
project employs all delivery processes needed to meet requirements. Quality assurance is a periodic or ongoing evaluation of the projects quality process with the
objective of deciding whether the projects work products are meeting the stated or implied needs of the project. A secondary purpose is to assure the stakeholders that
the system is producing appropriate and acceptable work products and that the sum of the work products will equal the projects objectives.
This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MPQ Manage Project Quality
Back to Top
WORK PRODUCT
Managed Quality Assurance - Managed Quality Assurance is the execution of the Quality Management Plan to ensure that the project employs all delivery processes
needed to meet requirements.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
Component
Description
1 Monitor specific project results from the quality control process to ensure compliance with quality objectives. Quality Compliance
2 Conduct planned and systematic activities (for example, Quality Reviews) to increase confidence that quality
planning objectives are met.
Fulfilled Quality Planning
Objectives

3 Monitor project management, quality management and execution processes for effectiveness. Updated Quality
Management Plan

Back to Top
APPROACH
The person who performs the Quality Assurance process (either the project manager or the quality manager) will have to evaluate the projects quality and delivery
processes with the objective of deciding whether the projects work products are meeting their stated objectives. A secondary purpose is to assure the stakeholders that
the system is producing appropriate and acceptable work products and that the sum of the work products will equal the projects objectives.
While performing quality assurance you may learn that the projects quality needs have changed or were stated incorrectly. Take this information back to the Quality
Planning Process step to redefine the needs, the standards, or the Quality Control processes, as needed. If you skip this step, you risk completing the project according
to the stated needs, but have the customer view it as a failure.
There will also be unplanned opportunities to gather information about project quality. For example, any time someone complains about something going wrong
repeatedly, you should identify it as an opportunity to find out which part of the quality process needs attention.
The inputs to this task are the Quality Management Plan, work performance information from quality control and testing activities, implemented corrective and preventive
actions as well as the whole Project Management Framework.
The output of this process are requested changes and recommended corrective actions to existing quality activities.
Tools and Techniques
The primary tool of the Manage Quality Assurance task is the Quality Review.The Quality Review is normally conducted by the quality manager and/or project manager.
The questions below should be answered during this task step. They allow the person conducting the review to assess whether the Quality Management Plan is
achieving the desired results and, if not, where the problem resides.
Quality Assurance questions regarding Quality Management:
Were any work products rejected or otherwise non-compliant?
Are the quality standards being met?
Are the quality management processes being followed?
Quality Assurance questions regarding Quality Planning:
Are the quality control processes effective?
Should additional work be reviewed by quality control?
Are some quality standards missing?
Were the quality needs defined correctly?
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Perform the quality assurance. Depending on your project, you may have a designated quality manager in this role that reports
to the project manager.
85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Quality Management Plan (QM.010) Execute the Quality Assurance Process documented in the Quality Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM050_AUDIT_ACTION_REPORT.DOC
QM050_AUDIT_REPORT.DOC
QM050_QUALITY_REPORT.DOC
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
QM.060 - CONDUCT POST-PRODUCTION QUALITY REVIEW
Request, participate in, and respond to a Post-Production Quality Review. During Project Closure, conduct a final quality review to validate compliance and fulfillment of
the project's stated quality objectives prior to transitioning the Quality Control and Reporting Process to the client.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Post-Production Quality Review
Back to Top
TASK STEPS
No. Task Step Component Component Description
1 Conduct final review of specific project results from the Quality Control
process to comply with quality objectives.
Fulfilled Quality Objectives
2 Communicate the fulfilled quality performance (management information)
to all key stakeholders.
Quality Control
Performance Notifications
This component is the final Quality Control Performance
Notification.
3 Compile the review into one document. Post-Production Quality
Review
The Post-Production Quality Review is a compilation of all the
components into one document.
4 Document an lessons learned. Quality Management
Lessons Learned

Back to Top
APPROACH
Conduct a review of the Quality Control Checklist and document final fulfillment of project quality objectives. Document this analysis in the checklist or create a separate
Post-Production Quality Report. Provide this information to the client and transition the Quality Control and Reporting Process to the client.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Depending on your project, you may have a designated quality manager in this role that reports to the project manager. 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
QM060_CLIENT_SATISFACTION_REPORT.DOC MS WORD
QM060_PROJECT_HEALTHCHECK_CHECKLIST.DOC MS WORD
QM060_METRICS_REPORT.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[CM] CONFIGURATION MANAGEMENT
The objective of the Configuration Management process is to reduce project risk by defining appropriate management and control processes for important work products
including both documentation and software. A successfully implemented Configuration Management process reduces errors, rework and lost time related to configuration
problems such as installing incorrect versions of software, missed patches, obsolete or incorrect documentation.
The Configuration Management process is composed of an overall Configuration Management Plan and Processes, and specific, more detailed plans for tools,
documentation, software configuration, software release, environment and patch management, and controls. The Configuration Management Plan and Processes defines
the tools that will be used by the project, who on the project team is responsible for each area and what project work products will be formally managed. The
Configuration Management Plan and Processes, the Configuration Management Tools and the Documentation Management Plan should be created early in the Project
Start Up phase so that the project is well positioned to manage work products that are produced early in the project lifecycle.
Configuration Management identifies what configuration items will be managed for the project, how they will be identified, how baselines will be established, what
management processes will be used to track them, and what metrics will be established for reporting. Every project produces a number of work products that must be
placed in a secure repository and may require version control. The Configuration Management process defines:
what specific item configuration items will be produced by the project
how the items will be managed and at what level of detail will management will occur
what level of version control is required for each type of configuration items
what level of access is required for initiating, creating, and approving a change to any configuration item
what processes, procedures and controls apply to each type of configuration item
who is has responsibility for the execution of the Configuration Management process
what metrics will be used to support Configuration Management control
Configuration Items commonly produced during the course of a project include:
Project Documentation Items including (but not limited to):
Functional Specifications
Technical Specifications
Test Cases and Test Results
Any document considered a contractual deliverable
Scope Change Requests
Other Change Requests
Application Setup Documents
Workplan
Status Reports
Management Presentations
Client Signoffs
Key Emails
Software configuration items including (but not limited to):
Source Code for Extensions and Customizations
Reports
Database Configurations
Patches
Wrapper Installation Scripts
Seed Data
Additional significant items that require Configuration Management include environments and software releases.
Configuration Management is linked to change management, as changes to scope frequently imply changes to established baselines of configuration items.
The Configuration Management process provides guidance to the project manager and project team for establishing (or validating the establishment of) a sound
Configuration Management for the life of a project.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During the Project Start Up phase, the project manager creates a Configuration Management Strategy and Processes that defines:
what configuration items the project will produce
which specific Configuration Management plan will document the management of each configuration item or group of items
who has responsibility for completing each task in the Configuration Management process
how specific activities are the responsibility of the client or a third party
how activities that are responsibility of a client or third party will be integrated into the overall project plan and what status mechanism will be used
what metrics will be collected to track and report on the process
The project manager identifies any tools required to support the Configuration Management process. If additional tools are required, complete a tool evaluation and
selection, initiate the procurement process, and plan for installation or configuration of required tools.
The final Configuration Management task in the Project Start Up phase is the completion of the Documentation Management Plan. The Documentation Management
Management Plan must be completed prior to the start of Project Execution and Control in order to provide an established Project Library before documentation
configuration items are produced.
The Software Configuration Management plan can be completed early in the Project Execution and Control phase, in parallel with the creation of the functional and
technical specification work that precedes the development of code.
Project Execution and Control Phase
During the Project Execution and Control phase, the project manager is responsible for establishing the Software Configuration Management Plan, the Software Release
Management Plan, the Environment and Patch Management Plan and the Configuration Management Control Plan. In addition, the project manager is responsible for
monitoring the key elements of configuration management identified in the Configuration Management Control Plan and making any adjustments, as necessary.
Establishment of appropriate metrics helps the project manager track and monitor the effectiveness of the Configuration Management process. Metrics provide a tool that
assist in early identification of issues or problems that may be encountered during the execution phase. Specific metrics should be established based on the particular
project requirements. Common metric examples include:
number of configuration items by type (how many source code objects checked in, how many patches applied, how many documented checked in)
number of configuration items that required updates after initial approval
number of defects by type
number of change requests, approved changes
number of source code packages contained in a particular system release
time-related statistics (how long from patch request to patch application, how long to update a particular item, etc., how long to obtain approvals, etc.)
Choose metrics that can be collected using the processes and procedures defined. If Configuration Management tools are used or planned, the tool often produces a
variety of metrics that can be reported. If tools are not in place, evaluate any suggested metric for the value it provides against the effort required to collect, particularly if
the collection effort is manual.
Project Closure Phase
During the Project Closure phase, the project manager records and documents all final versions of configuration items, validates that the client and/or partner have been
given the appropriate version of any contractual deliverables and archives all configurable items in an offsite secure location. The project manager should also
understand and comply with any applicable record retention rules.
Configuration Manager
Some projects have a dedicated configuration manager. If so, the configuration manager, with guidance from the project manager, plans, establishes and controls the
Configuration Management process on the project, with the following responsibilities:
Develop, document and implement Configuration Management Plan and Processes.
Establish project baselines and determine the content of project releases.
Ensure that no authorized changes are made to a project baseline.
Enforce configuration management procedures across all project processes.
Establish and ensure that the Enterprise Repository is adequately maintained and protected against damage or loss.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS CM.010 Develop Configuration Management Strategy and Processes Configuration Management Plan and Processes Y Core
PS CM.020 Obtain Configuration Management Tools Configuration Management Tools Core
PS CM.030 Create Project Documentation Management Plan Documentation Management Plan Core
Project Execution and Control
PEC CM.040 Create and Execute Software Configuration Management Plan Software Configuration Management Plan Y Core
PEC CM.050 Create and Execute Software Release Management Plan Software Release Management Plan Y Core
PEC CM.060 Create and Execute Environment and Patch Management Plan Environment and Patch Management Plan Core
PEC CM.070 Create and Execute Configuration Control Plan Configuration Management Control Plan
Project Closure
PC CM.080 Close Configuration Management Closed Configuration Management Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager
Depending on your project, you may have a designated configuration manager in this role that reports to the project manager.
Technical
Lead
This role is filled by a technical project team member (for example, developer, designer, system architect) acting in an advisory capacity.
Functional
Lead
This role is filled by a functional project team member (For example, business analyst, application/product specialist) acting in an advisory capacity.
Client (User)
CPS Client
Project
Sponsor

CPM Client
Project
Manager

Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.010 - DEVELOP CONFIGURATION MANAGEMENT
STRATEGY AND PROCESSES
In this task, you develop and document the Configuration Management Plan and Processes. This task has four objectives:
1. Identify the which specific configuration items will be produced by the project.
2. Identify the approach used to manage and each configuration item or groups of configuration items.
3. Identify any software tools required to implement the configuration management strategy.
4. Establish the high-level metrics that will be used to measure the effectiveness of the Configuration Management process.
The first step is to identify which specific configuration items will be produced by the project. A configuration item is a unit of configuration that can be individually
managed or versioned. Units with similar requirements may be combined into an overall collection that is managed under the same set of processes and tools.
Configuration Items commonly produced during the course of a project include:
Project Documentation Items including (but not limited to):
Functional specifications
Technical specifications
Test Cases and Test Results
Any document considered a contractual deliverable
Scope change requests
Other change requests
Application setup documents
Software configuration items including (but not limited to):
Source code for extensions and customizations
Database configurations
Patches
Wrapper installation scripts
"Gold instance" setups
Seed data
Additional significant items covered by the Configuration Management processes are the environment or instance strategy, the patch management process and the
software release strategy. A single approach to configuration management that satisfies the requirements of all configuration items may not be available. The
Configuration Management process includes separate tasks to create plans for Project Documentation Management, Software Configuration Management, Environment
and Patch Management and Software Release Management in addition to the Configuration Management Plan and Processes. In the Configuration Management Plan
and Processes, identify what configuration items will be created, which configuration item types are associated with which specific management plan, and avoid detailing
all the processes for versioning, control and management. That information will be detailed in the appropriate plans.
The Configuration Management Plan and Processes is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Configuration Management Plan and Processes - The Configuration Management Plan and Processes documents the strategy, approach and processes to be used
for Configuration Management on the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Prepare an introductory overview of the Configuration Management process. Introduction Document the Purpose, Scope and
Application and other applicable
introductory information.
2 Identify the specific configuration items. Configuration Items Document the different configuration
items.
3 Group configuration items with similar requirements together and assign them to a specific
management plan.
Configuration
Management Plans
Document each plan with a brief
description and list the configuration
items for each plan.
4 Review available software tools and identify if any additional tools needed to support the
configuration management requirements of the project.
Configuration
Management Tools
Document any software tools.
5 Identify any responsible parties outside the immediate project team that will participate in the
Configuration Management process, such as an existing client Configuration Management group.
Document how coordination with such a group will work.
Roles and
Responsibilities
Document all responsible parties.
6 Identify the metrics that will be used to measure the Configuration Management process and how
they will be collected.
Metrics Document the metrics.
7 Obtain key stakeholder agreement and approval on the Configuration Management Plan and
Processes.
Approved
Configuration
Management Plan and
Processes
Obtain any necessary sign-off or
Approval Certificate.
8 Distribute and communicate the Configuration Management Plan and Processes. Configuration
Management Plan and
Processes
File the plan for easy reference.
Back to Top
APPROACH
Configuration Management identifies what configuration items will be managed for the project, how they will be identified, how baselines will be established, what
management processes will be used to track them, and what metrics will be established to report on the Configuration Management process. Every project produces a
number of work products that must be placed in a secure repository and may require version control. The Configuration Management process defines
what specific item configuration items will be produced by the project
how the items will be managed and at what level of detail will management will occur
what level of version control is required for each type of configuration items
what level of access is required for initiating, creating, and approving a change to any configuration item
what processes, procedures and controls apply to each type of configuration item
who is has responsibility for the execution of the Configuration Management processes and procedures
what metrics will be used to support Configuration Management control
Two common risks associated with Configuration Management are that either the configuration items are under defined (not all items that should be baselined or tracked
are covered by the process) or the reverse, the Configuration Management items and their associated control process over defined (so much effort is required to comply
tracking and control processes that overall project productivity is reduced.). For many types of configuration items, there are limits to effective configuration management
unless specialized tools are used that provide the necessary capabilities. As a result, this is a difficult area to manage practically and requires an operational focus.
When the project manager designs the configuration management process the goal must be provide effective tracking and control while avoiding nonproductive
"overhead" that slows the progress of the project. Care must be taken when using manual processes and controls put in place to assure that the manual processes are
in fact followed.
If configuration software tools are going to be purchased, a milestone to note when the tools need to be set up and ready must be added to the project workplan. A
dependency to this milestone must be added to the project tasks that rely on the new configuration software tools.
Metrics
Establishment of appropriate metrics helps the project manager track and monitor the effectiveness of the configuration management process. Metrics provide a tool that
assist in early identification of issues or problems that may be encountered during the execution phases. Specific metrics should be established based on the particular
project requirements but common example metrics include:
number of configuration items by type (how many source code objects checked in, how many patches applied, how many documents checked in)
number of configuration items that required updates after initial approval (changes to the baseline)
number of change requests to baselined items, number of approved changes
number of source code packages or components contained in a particular system release
time related statistics (how long do requests to promote or approve items take?)
Choose metrics that can be collected using the processes and procedures defined. If configuration management tools are in use or planned, the tool usually produces a
variety of metrics that can be reported. If tools are not in place, include metrics to that allow quick checks on the effectiveness of the manual process. Evaluate any
suggested metric for the value it provides against the effort required to collect, particularly if the collection effort is manual
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Depending on your project, you may have a designated configuration manager in this role that reports to the project manager. 85
Client Project Sponsor *
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) acting in an advisory
capacity.
*
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Configuration Management requirements that should be taken into
consideration when developing the detailed Configuration Management Plan and Processes.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM010_CONFIGURATION_MANAGEMENT_PLAN_AND_PROCESSES.DOC MS WORD
CM010_CONFIGURATION_MANAGEMENT_PROCEDURES.DOC MS WORD (Former PJM 2.6.1 template)
CM010_CONFIGURATION_ITEM_INDEX.XLS MS EXCEL
CM010_CONFIGURATION_ITEM_STATUS_RECORD.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.020 - OBTAIN CONFIGURATION MANAGEMENT TOOLS
The requirements for configuration management tools for the project are defined in the Configuration Management Plan and Processes. In this task, the project manager
with the assistance of the technical lead procures/obtains, installs and configures the tools required. Options available to the project manager to obtain the tools include
but are not limited to the following:
Assist client in procuring tools.
Obtain licenses for required tools.
Obtain open source tools
Assist client in obtaining additional licenses for client-owned tools.
If new tools are obtained or procured, the technical lead or client team is responsible for installing and configuring the tools for the project team's use. Documentation and
training materials for the tools should be uploaded to the designated project location (both physical and computer-based) and communicated to the project team.
In the event the client does not have configuration management tools and is unwilling or unable to procure them, a risk should be created through the Risk Management
Process (RKM.020). Development of software without a tool that provides basic version control and software configuration management capabilities is a high risk for the
project.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Configuration Management Tools - Configuration Management Tools are the tools listed in the Configuration Management Plan and Processes installed and
configured.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Procure or obtain tools defined in the Configuration Management Plan and Processes. Procured Tools
2 Install/configure tools. Configuration Management Tools
3 Upload tool documentation and training materials to the designated project location(s). Tool Documentation and Training Materials
Back to Top
APPROACH
The approach to this task is:
Procure or obtain tools defined in the Configuration Management Plan and Processes.
Install/configure tools.
Upload tool documentation and training materials to the designated project location(s).
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
5
Project Manager Depending on your project, you may have a designated configuration manager in this role that reports to the project manager. 15
Client Project Sponsor *
Technical Leads This role is filled by technical project team members (e.g., developer, designer, system architect) providing needed technical
information.
80
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Configuration Management Plan and Processes (CM.010) The Configuration Management Plan and Processes lists the tools that will be used for the project.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.030 - CREATE PROJECT DOCUMENTATION MANAGEMENT
PLAN
The objective of this task is to define a clear structure to manage project documents that the project team can follow when creating and storing project documents and to
assure that all documentation produced by the project is stored in a defined location, with appropriate version control and that changes made to documentation
configuration items can be tracked and audited. The plan should specify the following:
naming standards for documents
standards for the composition of document reference numbers or version control scheme
document repository folder and directory structures
specific storage location requirements for each document configuration item type
the process to identify and track the status of all document configuration items
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Documentation Management Plan - The Documentation Management Plan documents a clear structure for document management that the project team can follow
when creating and storing project documents, the location where all documentation is stored, and the document version control procedures.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Prepare an introductory overview. Introduction Document the Purpose, Objectives and Glossary and and other
applicable introductory information.
2 Establish definitions. Determine the definitions of "baseline" that apply to
documentation management.
Glossary Document the configuration item and baseline definitions.
3 Identify the specific configuration items. Documentation
Configuration
Items
Document the different configuration items. The Documentation
Configuration Items were initially defined in the Configuration
Management Plan and Processes.
4 Review contract requirements regarding document repository tool and
logistics.
Requirements Document the requirements.
5 Define any processes and procedures that govern document management. Documentation
Processes and
Procedures
Document any processes and procedures that govern document
management.
6 Document process controls that can be used to validate that document
management requirements, and any processes and procedures that are
followed during the course of the project.
Process Controls Define the process controls.
7 Ensure any project documentation standards are used. Standards Document or reference any standards.
8 Define the process to assure that implementing team intellectual capital is
protected.
Intellectual
Capital
Protection
Process
Document or reference any processes.
9 Define the process to assure that client information protection policies are
followed.
Client Intellectual
Capital
Protection
Process
Document or reference any processes.
10 Design metrics to measure the effectiveness of the Document Management
plan.
Metrics Document the metrics.
#TOP #Top
11 Obtain key stakeholder agreement and approval on the Documentation
Management Plan.
Approved
Documentation
Management
Plan
Obtain any necessary sign-off or Approval Certificate.
12 Distribute and communicate the Documentation Management Plan. Documentation
Management
Plan
File the plan for easy reference.
Back to Top
APPROACH
If the project is using a software tool to manage and control project documentation, the tool may provide a comprehensive document index. If manual tracking is used the
project manager should create a documentation index or a work product tracking log that covers all documents that the project plans to produce.
Examples of common configuration items that should be covered by the Documentation Management Plan:
functional specifications
technical specifications
test cases and test results
any document considered a contractual deliverable
scope change requests
other change requests
acceptance certificates or client sign off documents
work product or deliverable documents
The Documentation Management Plan should define what is considered a baseline for any document that is a formal configuration item. A baseline implies that the
document is in a state that requires it to enter the process of formal configuration control. The Configuration Management Control Plan defines the change control
mechanisms that will be used to request changes and approve changes related to baselined configuration items.
The Documentation Management Plan should also discuss the retention of project documentation not considered formal configuration items. While these items may not
be subject to change control procedures, they represent important project artifacts and should be retained in the designated physical location or repository folder.
Examples of such items include:
team status reports
emails documenting key decisions or recommendations
management presentations
workshop material or presentations
checklists used to support processes
templates produced by the project that could be reusable
Project documentation represents a significant portion of the effort in any project. The project manager must design and document a process that:
tracks all documents that are expected to be produced
tracks the reasons why changes to baseline documents were required
tracks what changes have been made
It is very important that any change be traceable and that the effort associated with change be quantifiable.
The project documentation also represents a significant amount of intellectual capital. In cases when the primary document repository resides on a client-owned network
or in a client-owned repository, the project manager must design and implement an effective process to assure that a copy of all the implementing organization's
intellectual capital is stored and protected.
When creating the Documentation Management Plan, the project manager should:
Review contract requirements for any specific requirements related to the document repository or management process.
Review local requirements related to document management.
Identify and document requirements, processes, procedures and controls related to document management.
Establish and document the requirements that constitute a "baseline" for a document configuration item.
Identify and document what procedure will be followed to request changes to baselined versions of documents.
Identify and document what procedure will be followed to when changes to baselined versions of documents are authorized.
If the client will provide a third party software tool to manage the document repository, identify and document any process or procedures required to access the
tool. Identify any training that may be required for the project team and add the training effort to the Project Workplan.
If the project is using a third-party software tool, establish a process to move the implementing organization's intellectual capital to an appropriate repository
location.
Document naming standards to be followed. If manual version control will be used, create naming standards that support the version control effort.
Establish a control process to assure that all documentation is being checked in to the document library in the proper folders and that the document adheres to
naming conventions, version control requirements, etc. If a software tools is used, the tool itself may provide the required controls.
Establish a control process to assure that sensitive implementing organization information is secured and not maintained on client environment.
Establish a control process to assure that project documentation standards are used.
Document client requirements relating to information protection.
Establish and document the requirements that constitute a "baseline" for a document configuration item.
Identify and document what procedure will be followed when changes are required to baselined versions of documents.
Identify any client or project specific logos, heading or footing requirements that should be used when producing project documents.
For some projects, the project manager may elect to include additional documentation, such as status reports, meeting minutes, presentations or workshop materials
given to the client or other documents. It is recommended that any recommendation given to the client, particularly those relating to activities outside of the direct scope
in the project should be formally documented and included as a configuration item in the project documentation repository. Recommendations given informally via email
or other method may be "lost" by the client and if the recommendations relate to a topic that could impact client success, a history of having provided the recommendation
can be useful if an issue related to the recommendation arises.
Establishing Baselines
As with all configuration management terms there are number of definitions of the term "baseline". The IEEE Std. 610.12-1990, IEEE Standard Glossary of Software
Engineering Terminology defines baseline in two ways:
Baseline:
1. A specification or product that has been formally reviewed and agreed upon, thereafter serves as the basis for further development, and can be changed only
through formal change control procedures.
2. A document or a set of such documents formally designated and fixed at a specific time during the life cycle of a configuration item.
(IEEE Std. 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology (corrected edition). IEEE Standards Collection--Software Engineering, 1993
Edition, Institute of Electrical and Electronics Engineers, Inc., New York, 1993.)
The project manager needs to establish reasonable baselines related to document management that protect the implementing organization and the project from the risk
of lost work. If only "final" documents are loaded as in definition 1 above, the risk is that not all documents will be available if something unforeseen occurs. This could
be a small problem if the level of effort to produce the document was small, but for some project documents, the level of lost effort could be considerable. A second
definition of "baseline" similar to definition 2 above may be needed in order to define when a document should enter the document management process in a draft form.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Depending on your project, you may have a designated configuration manager in this role that reports to the project manager. 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level configuration management requirements that should be taken into
consideration when developing the detailed Documentation Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM030_DOCUMENTATION_MANAGEMENT_PLAN.DOC MS WORD
CM030_DOCUMENT_INDEX_WORD.DOC MS WORD (Former PJM 2.6.1 template)
CM030_DOCUMENT_INDEX_EXCEL.XLS MS EXCEL
CM030_DOCUMENT_UPDATE_NOTICE.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.040 - CREATE AND EXECUTE SOFTWARE
CONFIGURATION MANAGEMENT PLAN
The creation and execution of the Software Configuration Management (SCM) Plan is located in the Project Execution and Control phase rather than the Start Up phase
because actual software configuration items are not usually produced during Start Up, and the Document Management Plan is considered a more immediate need in the
lifecycle of a project. However, the SCM Plan must be created early in the Project Execution and Control phase before any objects are altered or produced. The SCM
Plan defines the process and controls for software configuration management. The specific details of software configuration management are often tightly aligned to the
requirements of the software configuration management tool selected during the Start Up phase of the project.
The Software Configuration Plan should include:
Identify any training needed related to the specific Software Configuration Management tool(s) and reference to training material.
Identify and document who has responsibilities related to each software configuration management tool(s) and process.
Identify "baseline" requirements that apply to each software configuration management item or group of items.
Identify and document the procedure to be followed to request changes to baselined versions of SCM items.
Identify and document the procedure which will be followed when changes to baselined versions of SCM items are authorized.
Define the policies and procedures for check in and check out of each software configuration item using the selected tool.
Define the access policy for software configuration tools.
Include any references to project naming standards related to software configuration items.
Identify any coding standards related to the Software Configuration Management process.
The creation of the SCM Plan is done early in the Project Execution and Control phase. The execution of the plan is ongoing throughout the Project Execution and Control
phase.
ACTIVITY
PEC.ACT.CECRM Create and Execute Configuration and Release Management
Back to Top
WORK PRODUCT
Software Configuration Management Plan - The Software Configuration Management (SCM) Plan defines the process and controls for software configuration
management.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify training and access requirements related to the
software configuration management tool.
Training and Access
Requirements
Document training and access requirements related to the
software configuration management tool.
2 Identify responsibilities related to SCM tools and processes. Roles and Responsibilities Document the roles and responsibilities.
3 Define procedures for establishing and changing baseline
software configuration management items.
Establish and Change SCM
Baselines Procedures
Document procedures for establishing and changing baseline
software configuration management items.
4 Define policies and procedures for check in and check out. Check In and Check Out
Procedures
Document policies and procedures for check in and check out.
5 Define naming and coding standards related to software
configuration items.
Naming and Coding Standards Document naming and coding standards related to software
configuration items.
6 Define any control processes that relate to software
configuration management.
Control Processes Document any control processes that relate to software
configuration management.
7 Obtain key stakeholder agreement and approval on the
Software Configuration Management Plan.
Approved Software
Configuration Management
Plan
Obtain any necessary sign-off or Approval Certificate.
8 Distribute and communicate the Software Configuration
Management Plan.
Software Configuration
Management Plan
File the plan for easy reference.
9 Execute the Software Configuration Management Plan.
Back to Top
APPROACH
Examples of Software configuration items include:
Source code for extensions and customizations
Reports
Database configuration or parameters
"Wrapper" installation scripts
"Gold instance" setups
Seed data
Application setups
The Software Configuration tool(s) and processes can be owned by the client, provided by Oracle, purchased by the client for the project, or an open source product.
There can be multiple tools used to track various configuration items. It is the project manager's responsibility to present a cohesive plan to the customer for managing
the many type of configuration items and to identify and document the responsibilities. It is recommended that the project manager assign the functional and technical
leads the responsibility of documenting the policies and procedures for managing software configuration. In the event the project is using client tools, any existing client
policies and procedures should be included in the Project Documentation library and communicated to the team through a training event or a workshop.
Enterprise Repository
If an Enterprise Repository is to be used for the project, make sure it is set up during this task. The enterprise may already have a repository or one may already have
been set up as part of an Envision engagement.
Back to Top
SUPPLEMENTAL GUIDANCE
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Depending on your project, you may have a designated configuration manager in this role that reports to the project manager. 85
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) acting in an advisory
capacity.
*
Functional Lead This role is filled by a functional project team member (e.g., business analyst, application/product specialist) acting in an
advisory capacity.
*
Client Project Sponsor *
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Governance Implementation (ENV.GV.100) If an Enterprise Repository is to be used for the project, check and see if one has already been set up in as as part of
an Envision engagement. It would have been installed and governed as part of Governance Implementation.
Configuration Management Tools (CM.020) The Configuration Management Tools specifies the tools to be used to execute the Software Configuration
Management (SCM) Plan.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
SOA Service Lifecycle Use this technique for guidance on how version control should be set up for services and dependent components.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM040_SOFTWARE_CONFIGURATION_MANAGEMENT_PLAN.DOC MS WORD
Tool Comments
Oracle Enterprise Repository The Oracle Enterprise Repository is a COTS Enterprise Repository tool solution that is used to establish and
maintain an Enterprise Repository.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.050 - CREATE AND EXECUTE SOFTWARE RELEASE
MANAGEMENT PLAN
A software release refers to the creation and availability of a new version of computer software product or a group of configuration items.
Release planning is the activity of determining a feasible combination of dates, features, components and resourcing for the next release of an existing software product.
The creation and execution of the Software Release Management governs the process used to assemble the components of a software release and the process used to
distribute the changes or the changed system to those people using it. It describes the contract between the project software development team, the project manager
(who coordinates the plan on behalf of the business), and the client project team.
A software release is composed of a collection of configuration items that may include:
Source code for extensions and customizations
Reports
Database configurations
"Wrapper" installation scripts
"Gold instance" setups
Seed data
Application setups
Release notes
Functional and Technical specifications related to the components of the release
The specific requirements of creating a software release may be tightly tied to the configuration management tools in use by the project.
Responsibilities of the project manager are:
Determine and document a policy for iterative software releases including milestones, time scales and supporting techniques to be employed.
Develop procedures and processes for software releases including any forms and tracking tools being used for the process.
Determine responsibilities for team members in the software release process.
Communicate to the client and project team the policies and procedures for software releases and gain their agreement.
Establish metrics that can be used to measure the effectiveness of the software release process.
Monitor that the work performed adheres to procedures for release management and migration.
The creation of the Software Release Management Plan is done early in the Project Execution and Control phase. The execution of the plan is ongoing throughout the
Project Execution and Control phase.
ACTIVITY
PEC.ACT.CECRM Create and Execute Configuration and Release Management
Back to Top
WORK PRODUCT
Software Release Management Plan - The Software Release Management Plan documents the process used to assemble the components of a software release and
the process used to distribute the changes or the changed system to those people using it. It describes the contract between the project software development team, the
project manager (who coordinates the plan on behalf of the business), and the client project team.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Define a policy for software releases . Software Release Policy Document the policy for software releases.
2 Create or obtain and software release forms. Software Release Forms Document or reference the forms.
3 Define procedures and processes for software releases including
any forms and tracking tools being used for the process.
Tracking Tools
Procedures and
Processes
Document procedures and processes for software releases including
any forms and tracking tools being used for the process.
4 Define responsibilities for team members in the software release
process.
Roles and
Responsibilities
Document the roles and responsibilities.
5 Establish metrics to measure the effectiveness of the software
release process.
Metrics Document the metrics
6 Obtain key stakeholder agreement and approval on the Software
Release Management Plan.
Approved Software
Release Management
Plan
Obtain any necessary sign-off or Approval Certificate.
7 Distribute and communicate the Software Release Management
Plan.
Software Release
Management Plan
File the plan for easy reference.
8 Execute the Software Configuration Management Plan. Make sure work performed adheres to procedures for release
management and migration.
Back to Top
APPROACH
Software release management is the responsibility of the project manager with the assistance of the technical and functional lead, the client project manager and the
configuration manager (if the project has someone in that role). It is recommended that the software configuration management tool selected for the project provide the
capabilities to build and manage software configuration releases. If such capabilities are not available, the project manager should evaluate the effort to support the
release process and potentially add resources. For large projects, or projects with numerous custom objects, tracking the release manually using a spreadsheet or other
paper based tool can require considerable effort.
SOA Release Planning Considerations
If the project is part of a wider service-oriented architecture (SOA) strategy, the Software Release Management Plan should contain SOA services that may be required by
other projects or may be dependant on other projects to provide SOA services. Because SOA increases the interdependencies across projects and even to some extent
within a project, software release planning in SOA projects is slightly more complex. If you are in on SOA project that is part of a wider SOA initiative, please refer to the
SOA Release Planning Technique for more details.
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
SOA Project Delivery Implementations
This task has supplemental guidance that should be considered if you are doing a SOA Project Delivery implementation. Use the following to access the task-specific
supplemental guidance. To access all SOA Project Delivery supplemental information, use the OUM SOA Project Delivery Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Depending on your project, you may have a designated configuration manager in this role that reports to the project manager. 85
Client Project Sponsor *
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) acting in an advisory
capacity.
*
Functional Lead This role is filled by a functional project team member (e.g., business analyst, application/product specialist) acting in an
advisory capacity.
*
Client Project Manager *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Configuration Management Plan and Processes
(CM.010)
The Configuration Management Plan and Processes identifies the software configuration items that will be
produced and managed by the project.
Back to Top
TECHNIQUES
The following techniques are available to assist with this task:
Technique Comments
SOA Release Planning For SOA engagements, this technique defines leading practices for SOA release planning.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM050_SOFTWARE_RELEASE_MANAGEMENT_PLAN.DOC MS WORD
CM050_RELEASE_NOTE.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.060 - CREATE AND EXECUTE ENVIRONMENT AND PATCH
MANAGEMENT PLAN
The Environment and Patch Management Plan defines the requirements, processes and procedures that govern environment and patch management for the project.
The Environment and Patch Management Plan should :
Define the technical environments that are required to support the project implementation and document their intended purpose. Identify the users that will be using
the environment. Identify the timeline for establishment of each project environment. Identify the timeline for decommissioning of each project environment.
Document the source of data for each environment. Define the access policies related to each environment. Document the "flow of control" as it relates to the
application of patches and software releases that are applied to each environment. Document the policies, processes and procedures to required to manage
configuration changes to the environments such as applying patches. Document the tools and techniques to manage the environments (creation, refreshing,
backup, patching, etc.).
Document the tools and techniques to monitor the status of the environments.
All environments should serve a specific purpose (development, test, quality assurance, production, etc.) and some have a limited life span. The Environment and Patch
Management Plan should document the processes required to create a new environment and to refresh an existing environment by cloning from another environment.
The plan should also specify the change control procedures that govern the application of patches. Application of patches may be mandatory to fix problems of an urgent
nature. Emergency and escalation procedures should be documented in Environment and Patch Management plan to permit the project team to react appropriately if the
need arises.
The creation of the Environment and Patch Management Plan is done early in the Project Execution and Control phase. The execution of the plan is ongoing throughout
the Project Execution and Control phase.
ACTIVITY
PEC.ACT.CECRM Create and Execute Configuration and Release Management
Back to Top
WORK PRODUCT
Environment and Patch Management Plan - The Environment and Patch Management Plan documents the requirements, processes and procedures that govern
environment and patch management for the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Define the strategy for environment and patch management. Strategy Document the strategy, objectives and key principles.
2 Define the project environments. Project Environments Document the various environments that will be used on the project
(for example, production, test, training, etc.).
3 Define the access policies related to each environment. Access Policies Document the access policies related to each environment.
4 Define the procedures to create, clone, and backup
environments.
Environment Procedures Document the procedures to create, clone, maintain and backup
environments.
5 Define any implementation environment hardware
requirements.
Implementation Environment
Hardware Requirements
Document any implementation environment hardware requirements.
6 Identify the tools and techniques for managing and
monitoring environments.
Environment Tools and
Techniques
Document the tools and techniques for managing and monitoring
environments.
7 Define policies and procedures for managing patches. Patch Management Procedures Document policies and procedures for managing patches.
8 Identify the tools and techniques for applying patches. Patch Tools and Techniques Document the tools and techniques for applying patches.
9 Define the responsibilities related to testing patches. Roles and Responsibilities Document the roles and responsibilities.
10 Obtain key stakeholder agreement and approval on the
Environment and Patch Management Plan.
Approved Environment and
Patch Management Plan
Obtain any necessary sign-off or Approval Certificate.
11 Distribute and communicate the Environment and Patch
Management Plan.
Environment and Patch
Management Plan
File the plan for easy reference.
12 Execute the Environment and Patch Management Plan. Execute the Environment and Patch Management Plan as defined
by the Project Workplan.
13 Monitor the Environment and Patch Management
processes.
Take corrective action as necessary.
Back to Top
APPROACH
Environment and patch management is the responsibility of the technical lead for the project. If this is client owned, the project manager is required to document or post
the appropriate documents provided by the client to the project teams documentation library. The technical lead should consider using tools that are available to monitor
the status of the environments.
The technical team will commonly receive patches that fix particular problems or add certain functionality. The functional team or business user may request a patch that
adds additional functionality. Before applying a patches, the projects change control process should be used to evaluate risk, financial impact and schedule impact. It is
recommended that a patch environment is set up to "test" the patch before introducing the patch to a working environment. The Environment and Patch Management
Plan includes the following for patches:
policies and procedures for applying software patches
tools and techniques for applying software patches
references to the the Projects Change Management Process
tools and techniques for monitoring the configuration of the environment
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
5
Project Manager Review and approve the Environment and Patch Management Plan. Depending on your project, you may have a designated
configuration manager in this role that reports to the project manager.
15
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) designated to develop and
monitor the Environment and Patch Management Plan.
50
Functional Lead This role is filled by a functional project team member (e.g., business analyst, application/product specialist) designated to
develop and monitor the Environment and Patch Management Plan.
30
Client Project Sponsor *
Client Project Manager Review and approve the Environment and Patch Management Plan. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Configuration Management Plan and Processes (CM.010)
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM060_ENVIRONMENT_AND_PATCH_MANAGEMENT_PLAN.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.070 - CREATE AND EXECUTE THE CONFIGURATION
CONTROL PLAN
The Configuration Management Control Plan defines the control mechanisms that govern the Configuration Management process for the project. This task includes
defining the controls, identifying the team members responsible for executing the controls, documenting the controls and executing those controls as required throughout
the project lifecycle.
Examples of Configuration Management control include:
Processes to log, prioritize and categorize, and track change requests
Process to review and approve change requests
Process to schedule approved changes
Process to validate patches applied to appropriate environments
Process to audit that application configuration documentation matches actual environment configuration
Process to schedule, implement and validate software releases
Process to roll back unsuccessful changes and recover to a prior baseline
The creation of the Configuration Control Management Plan is done early in the Project Execution and Control phase. The execution of the plan is ongoing throughout the
Project Execution and Control phase.
ACTIVITY
PEC.ACT.CECRM Create and Execute Configuration and Release Management
Back to Top
WORK PRODUCT
Configuration Management Control Plan - The Configuration Management Control Plan documents the control mechanisms that govern the Configuration Management
process for the project.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Prepare an introductory overview. Introduction Provide introductory remarks.
2 Define Configuration Management control processes. Configuration Management
Control Processes
Document and describe the various CM processes.
3 Define and document configuration control metrics. Metrics Document configuration control metrics.
4 Identify tools and techniques to manage metrics. Tools and Techniques Document tools and techniques to manage metrics.
5 Define policies and procedures to control the identified
configuration items.
Configuration Items Policies
and Procedures
Document policies and procedures to control the identified configuration
items.
6 Define intersection points between Configuration
Management and other processes.
Intersection Points Document intersection points between Configuration Management and
other processes, particular Quality Management.
7 Define the responsibilities. Roles and Responsibilities Document the roles and responsibilities.
8 Obtain key stakeholder agreement and approval on the
Configuration Management Control Plan.
Approved Configuration
Management Control Plan
Obtain any necessary sign-off or Approval Certificate.
9 Distribute and communicate the Configuration
Management Control Plan.
Configuration Management
Control Plan
File the plan for easy reference.
10 Execute the Configuration Management Control Plan.
Back to Top
APPROACH
Controlling Configuration Management is a responsibility that is shared by the technical and functional leads. If the client has an established Configuration Management
group, they may be assigned the responsibility for Configuration Management control and the project may elect to leverage client processes that are already established.
If Configuration Management tools are in use, the tools may automate a number of the required controls, which eases the burden on the project team. What ever means
of controls are select, the project manager must design the controls in such a way to reduce project risk, while avoiding processes that are difficult to manage or
administer. If using processes already established by the client, the project manager should review those processes for any potential impact to the project work plan.
In addition to defining the processes for configuration management control, the Configuration Management Control Plan should also document the intersection points
between Configuration Management and other processes, particularly the Quality Management process. The creation of configuration items, including documents,
software and other artifacts should include specific quality inspections and reviews defined by the Quality Management process. The project manager should document
when Quality Management process tasks will occur for items under Configuration Management control. Examples include when code reviews will take, what levels of
testing are required to approve and promote a new software release, etc.
Specific control mechanisms vary depending on the project size, complexity and availability of configuration management tools. Some projects may establish a Change
Control Board, a group of individuals representing the various project teams, who review and approve all or a subset of changes. Some projects may have tools uses
workflow's to process and track changes and approvals. Some project may have dedicated code review teams, while others institute a peer review process. The
Configuration Management Control plan should document the specific control mechanisms planned and the parties responsible for implementing those controls.
Metrics
Metrics related to Configuration Management play an important role in Configuration Management control. Establishment of appropriate metrics helps the project
manager audit the Configuration Management process and identify areas of improvement. Metrics should also support the Configuration Management audit trail. Specific
metrics should be established based on the particular project requirements but common example metrics include:
number of configuration items by type status (how many source code objects checked in, how many patches applied, how many documented checked in)
number of configuration items that required updates after initial approval
number of change requests
number of approved changes
number of source code packages contained in a particular system release
time related statistics (how long from patch request to patch application, how long to update a particular item, etc., how long to obtain approvals, etc.)
Choose metrics that can be collected using the processes and procedures defined. If Configuration Management tools are in use or planned, the tool will often produce a
variety of metrics that can be reported. If tools are not in place, evaluate any suggested metric for the value it provides against the effort required to collect, particularly if
the collection effort is manual.
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Produce and execute the Configuration Management Control Plan. Depending on your project, you may have a designated
configuration manager in this role that reports to the project manager. If so, the project manager would review and approve the
Configuration Management Control Plan.
85
Client Project Sponsor *
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) acting in an advisory
capacity.
*
Functional Lead This role is filled by a functional project team member (e.g., business analyst, application/product specialist) acting in an
advisory capacity.
*
Client Project Manager Review and Approve the Configuration Management Control Plan. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Configuration Management Plan and
Processes (CM.010)
The Configuration Management Plan and Processes identifies the various configuration items that will be produced
and managed by the project.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM070_CONFIGURATION_MANAGEMENT_CONTROL_PLAN.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
CM.080 - CLOSE CONFIGURATION MANAGEMENT
During Project Closure, the project manager is responsible for closing out Configuration Management. This includes the following responsibilities:
Record and Document a current version of documentation, code, release, patches, and environments. It is a leading practice for projects to using a repository for
documentation or software configuration items.
If the project is using a repository for documentation or software configuration items, validate that copies of all final items that are Intellectual Capital are placed in
the project repository in the appropriate folders.
Validate that any sensitive material is removed from client environments, networks, PCs or other storage areas.
If appropriate, capture electronically hard-copy acceptance certificates and upload into the final project repository.
Finalize the archive of all project work products (hard copy and disks) according to policy requirements.
Document Configuration Management Lessons Learned
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Configuration Management
The Closed Configuration Management work product consists of the following components:
Finalized Documentation of Configuration Items
Project Work Products Archive
Configuration Management Lessons Learned Report
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Record current version of documentation and configuration items. Finalized Documentation of
Configuration Items
Document current version of documentation and
configuration items.
2 Finalize the archive of all project work products. Project Work Products
Archive

3 Remove all sensitive material from client environment. None
4 Create electronic images of all hard copy acceptance certificates and store
in the appropriate project Documentation Repository.
Project Work Products
Archive

5 Document any lessons learned. Configuration Management
Lessons Learned
This report is used to create the Lessons Learned report
produced in the Communication process.
Back to Top
APPROACH
All work products produced by the project should be retained in electronic format. If the project manager has hard copy of acceptance certification copies, electronic
copies should be created and stored in the appropriate Documentation Repository. Certificates can be scanned, or the project manager could fax them to himself and use
the .tif files created. If appropriate, all sensitive materials should be removed from the client environment.
Configuration Management Lessons Learned can be a separate document or used as part of the overall lessons learned document produced in the Communication
process.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
5
Project Manager Depending on your project, you may have a designated configuration manager in this role that reports to the project manager. 45
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) providing needed technical
information.
50
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Configuration Management Plan and Processes
(CM.010)
Documentation Management Plan (CM.030)
Software Configuration Management (SCM) Plan
(CM.040)
Software Release Management Plan (CM.050)
Environment and Patch Management Plan (CM.060)
Configuration Management Control Plan (CM.070)
Use these work products to identify any procedures for versioning and closing out each specific configuration
item type.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
CM080_CONFIGURATION_MANAGEMENT_LESSONS_LEARNED.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[IFM] INFRASTRUCTURE MANAGEMENT
Infrastructure Management involves identifying and documenting requirements, planning and managing the components of the project infrastructure. The project
infrastructure has two main components:
the Team Work Environment
the Established Technical Infrastructure
The Team Work Environment includes those technical components that support the project team directly while the Established Technical Infrastructure environment is
composed of the hardware and software components that comprise and support the application environments planned for the project.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During the Project Start Up phase, the project manager is responsible for establishing a stable and productive infrastructure to effectively manage and execute the project.
There are three Infrastructure Management tasks that occur during the Project Start Up phase:
Develop Infrastructure Management Plan
Establish Team Work Environment
Establish Technical Infrastructure
At the start of a project, the team requires PCs, printers, network access, user IDs to client systems, messaging, phone system access, VPN, office space and meeting
room space to work effectively. These requirements should be documented in the Project Management Framework and the project manager can use that as a starting
point to document the the Infrastructure Management Plan and Team Work Environment. The project manager should review the requirements and update any
requirements that were omitted or changed since the contract was executed.
If issues arise that prevent the project manager from obtaining appropriate work space or other project team infrastructure components, the project manager must move
quickly to resolve the issue and escalate, if necessary. For large projects or projects that are composed of virtual team members, lack of an effective or adequate Team
Work Environment can quickly become a critical path item that impedes project progress.
The project manager should establish and document the expected service levels related to the Established Technical Infrastructure, such as system availability and
backup requirements. Particular attention should be paid to availability requirements or service levels that apply to the development and test environments. For example,
if the project includes Global Blended Delivery, then system availability should be 24 by 7 to support development activities occurring in different time zones.
The project manager should also identify and document any required additional software, such as system management tools, system monitoring tools, backup and
archiving tools, testing tools, configuration management software, etc. (and servers to support them) that are stated or implied by the project scope. The detailed
requirements, architecture and deployment of these items should be covered by the Technical Architecture process. The Infrastructure Management plan should be
limited to identification and documentation of the high-level requirements and refer to the tasks in the execution method (Technical Architecture process) for the details.
Project Execution and Control Phase
During Project Execution and Control, the project manager monitors the Team Work Environment and the Established Technical Infrastructure and takes any corrective
action needed to assure that they are maintained at an acceptable level to support project activities.
If the project scope assigns partial or full responsibility for the implementation of the technical architecture to client personnel or third parties, the project manager should
detail who is responsible for each task in the Technical Architecture process and describe how the parties responsible will coordinate with the larger project team. Items
such as workplan activities, milestones, metrics, status, etc. should be described to avoid communication problems or issues during the project execution.
Metrics
Establishment of appropriate metrics helps the project manager track and monitor the effectiveness of the Infrastructure Management process. Metrics provide a tool that
assist in early identification of issues or problems that may be encountered during Project Execution and Control. Specific metrics should be established based on the
particular project requirements but common metric examples include:
Outputs from monitoring the Established Technical Infrastructure (CPU utilization, database statistics, network performance, etc.)
Performance against service-level requirements (how long does it take to establish a new environment once requested.)
Lost-time metric (amount of project development time lost due to unplanned outages)
Lead-time requirements (how long does it take to get a new team member's work environment set up, user ids established, etc.)
Choose metrics that can be collected using the processes and procedures defined. If infrastructure management tools are used or planned, the tools often produce a
variety of metrics that can be reported. If tools are not in place, evaluate any suggested metric for the value it provides against the effort required to collect, particularly if
the collection effort is manual. Identification of metrics as early as possible allows the project manager to have effective measurements to manage infrastructure, permit
earlier identification of issues or problems, and in the event that significant infrastructure issues arise, quantify the impact of those issues on the project timeline.
Project Closure Phase
The project manager must document and turn over the Team Work Environment and Established Technical Infrastructure to the client. Items representing Oracle
intellectual capital, project work in progress or consultant materials, not to be provided to the client, must be removed from client infrastructure and archived as described
in the Configuration Management process. Any client owned assets that were provided to the project team should be inventoried and returned. Consultant access to
client systems should be revoked.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS IFM.010 Develop Infrastructure Management Plan Infrastructure Management Plan Core
PS IFM.020 Establish Team Work Environment Team Work Environment Core
PS IFM.030 Establish Technical Infrastructure Established Technical Infrastructure Core
Project Execution and Control
PEC IFM.040 Manage and Maintain Infrastructure Maintained Infrastructure Core
Project Closure
PC IFM.050 Close Infrastructure Closed Infrastructure Core
Back to Top
OBJECTIVES
The objectives of the Infrastructure Management process are:
identify, document and implement the requirements, processes, procedures and controls pertaining to the Team Work Environment and the Established Technical
Infrastructure.
Provide a stable and effective infrastructure to support the project objectives and timeline.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager

Technical
Lead
This role is filled by a technical project team member (for example, developer, designer, system architect) acting in an advisory capacity.
Client (User)
CPS Client
Project
Sponsor

CPM Client
Project
Manager

Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IFM.010 - DEVELOP INFRASTRUCTURE MANAGEMENT PLAN
Infrastructure Management involves identifying, planning and managing the components of the project infrastructure. The project infrastructure has two main
components, the team work environment and the technical infrastructure environment.
The team work environment includes the technical components that support the project team. Examples include:
PCs
phones, pagers, beepers
printers, fax machines, copiers
VPN access into the client site
VPN access into the Oracle network
access to client networks
access to shared drives, 3rd party software tools etc.
consultant workspace, conference rooms
When specifying project software to be used, include the specific software and versions required.
The project manager is responsible for documenting the requirements, process and procedures related to the team work environment, while the client project manager is
typically responsible for acquiring the actual physical resources. The client project manager should supply any client specific processes to be followed to obtain access,
user ids, equipment, and workspace needed by the project team.
The requirements, processes, procedures and controls that apply to the team work environment should be fully documented in the Infrastructure Management plan.
The technical infrastructure environment includes the hardware and software components related to the project application environments. Examples include:
Servers
Network
IO subsystems
Third-party software tools
It is assumed that the project will follow an execution method that includes a comprehensive Technical Architecture process. In the Infrastructure Management process,
the project manager should identify and document the high level requirements needed to support the project technical infrastructure and environments. Examples of
these requirements include:
identified business requirements related to production performance or availability
implied requirements for the development and test environments related to the production environment (if RAC or GRID is planned, at least some of the
development or test environments will have to be RAC or GRID)
implied requirements for additional third party software tools (if performance testing is in scope, an automated testing tool may be required)
availability requirements for instances (if Global Blended Delivery 24/7 support may be needed)
backup requirements for development and test environments
service level agreements related to cloning environments, restoring from backups, application and patches, etc.
service level agreements related to the support of an infrastructure hosting provider
In the event that some or all of the technical infrastructure tasks are the responsibility of a client or third party, the project manager should document who has
responsibility for each task, what work products will be produced, how status will be communicated and how coordination between the parties will take place. When work
is being done by a separate project team, the project manager should document how activities will be monitored and tracked in the Project Workplan.
The Infrastructure Management Plan is the framework for the project manager to identify and document the requirements needed to establish a technical infrastructure
environment that is stable and meets the project implementation requirements. Detailed technical requirements, processes and procedures related specifically to the
technical infrastructure environment are documented and executed following the execution method that has been chosen for the project implementation.
The Infrastructure Management Plan is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Infrastructure Management Plan - The Infrastructure Management Plan documents the requirements needed to establish a technical infrastructure environment that is
stable and meets the project implementation requirements.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Provide an introduction. Introduction Document introductory remarks.
2 Identify team work environment requirements. Team Work Environment
Requirements
Document team work environment
requirements.
3 Define the team work environment processes, procedures and controls. Team Work Environment
Processes, Procedures and
Controls
Document the processes, procedures and
controls.
4 Identify high level technical infrastructure requirements and service levels. Technical Infrastructure
Requirements and Service Levels
Document high level technical
infrastructure requirements and service
levels.
5 Define high level technical infrastructure processes, procedures and controls. Technical Infrastructure
Processes, Procedures and
Controls
Document the processes, procedures and
controls.
6 Determine the responsibilities for establishing the technical infrastructure
environment Refer to Technical Infrastructure execution tasks for details.
Roles and Responsibilities Document the roles and responsibilities.
7 Establish infrastructure management metrics. Metrics Document the metrics.
8 Obtain key stakeholder agreement and approval on the Infrastructure Management
Plan.
Approved Infrastructure
Management Plan
Obtain any necessary sign-off or Approval
Certificate.
9 Distribute and communicate the Infrastructure Management Plan. Infrastructure Management Plan File the plan for easy reference.
Back to Top
APPROACH
At the start of a project, the team requires PCs, printers, network access, user ids to client systems, messaging, phone system access, VPN, office space and meeting
room space to work effectively. In the event that the project has a requirement for beepers, pagers, or special cell phones, this should be documented. These
requirements should be documented in the proposal or contract and the project manager should review those documents to determine if any requirements were omitted
or have changed and document them in the Infrastructure Management Plan. Any client processes or procedures that are required when consultants join the project
(forms to be filled out, individuals to be notified, etc.) should be documented.
If issues arise that prevent the project manager from obtaining appropriate work space or other project team infrastructure components, the project manager must move
quickly to resolve the issue and escalate if necessary. For large projects or projects that are composed of virtual team members, lack of an effective or adequate team
work environment can quickly become a critical path item that impedes project progress.
The project manager should establish and document the expected service level agreement that pertains to the Technical Architecture components of the technical
infrastructure environment such as system availability and backup requirements. Particular focus should be on the service levels required for the development and test
environments needed to support the project timeline and staffing plan. For example, if the project includes a Global Blended Delivery component, then system availability
should be 24 by 7 to support development activities occurring in different time zones.
The Project Manager should also identify and document any requirement for items such as system management tools, system monitoring tools, backup and archiving
tools, testing tools, configuration management software, etc. (and servers to support them) that are stated or implied by the project scope. The detailed requirements,
architecture and deployment of these items should be covered by the execution method Technical Architecture process. The Infrastructure Management Plan should be
limited to identification and documentation of the high level requirements and refer to the tasks in the execution method for the details.
As a general rule, while high level conceptual architecture can be included to enhance understanding, the project manager should avoid including detailed descriptions of
the planned technical architecture and refer instead to the associated execution method tasks. If the Project Workplan calls for an initial CRP environment that is needed
immediately on Project Start Up and is being provided by a hosting service, the Infrastructure Management Plan should refer to the documentation that establishes that
environment. The project manager may include a list of technical environments planned for the project, but specific environment details (how many instances will be
required, time frames, cloning procedures, etc.) should be defined in the Environment and Patch Management Plan produced in the Configuration Management process
as those requirements tend to evolve during the course of the Execution and Control phase.
Metrics
Establishment of appropriate metrics help the project manager track and monitor the effectiveness of the Infrastructure Management process. Metrics provide a tool that
assist in early identification of issues or problems that may be encountered during the execution phase. Specific metrics should be established based on the particular
project requirements but common example metrics include:
Outputs from monitoring the Technical Infrastructure (CPU utilization, database statistics, network performance, etc.)
Performance against service level requirements (how long does it take to establish a new environment once requested)
Lost time metrics (amount of project development time lost due to unplanned outages, missed maintenance windows, etc.)
Lead time requirements (how long does it take to get a new team member's work environment set up, user ids established, etc.)
Choose metrics that can be collected using the processes and procedures defined. If Infrastructure Management tools are in use or planned, the tools often produce a
variety of metrics that can be reported. If tools are not in place, evaluate any suggested metric for the value it provides against the effort required to collect, particularly if
the collection effort is manual. Early identification of metrics allows the project manager to have effective measurements to manage infrastructure, permits identification
of issues or problems, and in the event that significant infrastructure issues arise, help to quantify the impact of those issues on the project timeline.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager Create the Infrastructure Management Plan. 85
Technical Lead This role is filled by a technical project team member (e.g., developer, designer, system architect) that provides advisory
assistance in the creation of the Infrastructure Management Plan.
*
Client Project Manager Identify client-specific procedures and requirements for access, etc. *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Infrastructure Management requirements that should be taken into
consideration when developing the detailed Infrastructure Management Plan.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IFM010_INFRASTRUCTURE_MANAGEMENT_PLAN.DOC MS WORD
IFM010_INSTALLATION_AND_RECORD.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IFM.020 - ESTABLISH TEAM WORK ENVIRONMENT
Based on the requirements, processes, procedures and controls documented in the Infrastructure Management Plan, establish the project Team Work Environment. This
includes:
Establish appropriate technology infrastructure. This typically includes phones, PCs, laptops, printers, network access, email, voice mail and security access.
Establish software requirements, for example team members should have laptops configured with any required software. The project manager should specify the
expected version of software required and if specific software is required for specific roles.
Provide access to conference rooms and training facilities and understand how to reserve those facilities.
Establish a project room command center if needed.
Create a structure, both physical (file cabinets) and computer-based (Directory Structure) to post all project documentation in accordance with project
requirements.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Team Work Environment
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Establish the Team Work Environment. Team Work
Environment
Establish the Team Work Environment per the requirements
defined in the Infrastructure Management Plan.
2 Examine expected staffing levels and project requirements over the project
lifecycle that could impact the Team Work Environment.

3 Adjust the Team Work Environment over time if changes to the project require it
and notify the client project manager.

4 Monitor the metrics relating to Team Work Environment and make corrections
as necessary.

Back to Top
APPROACH
If project roles requires team members to be proficient with software tools, this should be identified as part of the requirements for the position. If team members are
required to have laptops with tools that have additional license costs, this should also be identified as part of the requirements for the position.
For large project, monitor the effectiveness of the Team Work Environment. The contract may have specified that the client provide "adequate" workspace, and if there
are issues or problems that prevent the team from working productively, the project manager must address them before they impact the project.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Infrastructure
Management Plan
(IFM.010)
The Infrastructure Management Plan documents the requirements needed to establish a technical infrastructure environment that is stable and
meets the project implementation requirements. It specifically provides the details for the Team Work Environment.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IFM.030 - ESTABLISH TECHNICAL INFRASTRUCTURE
Based on the requirements, processes, procedures and controls documented in the Infrastructure Management Plan, establish the project Technical Infrastructure. This
includes:
Oversee the installation and configuration of the project technical infrastructure environments, including hardware, software and application software.
Oversee the implementation of the project support infrastructure and system management tools including but not limited to backup, recovery, and archiving.
Begin procurement process for any additional third party software tools required.
Track the execution of these tasks against the time lines specified in the Project Workplan.
If client or third parties are responsible for some or all of the Technical Infrastructure tasks, begin coordination process documented in the Infrastructure
Management Plan.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Established Technical Infrastructure
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Install and configure project technical environments. Project Technical Environments
2 Implement project support infrastructure and system management tools. Project Support Infrastructure and System Management Tools
3 Begin Procurement of any software required by project.
Back to Top
APPROACH
The project manager should make sure that the requirements related to the Technical Infrastructure are driven by the needs of the project, not the constraints of the
client, particularly as they relate to the service levels, management and maintenance of the development and test environments.
Clients sometimes wish to limit access to hardware or other components of the Technical Infrastructure due to resource or budget constraints. The project manager must
work with the client to help them understand how the requirements relate to the objectives of the project, what risks are involved if the requirements are not met and to
assure that a stable and adequate technical infrastructure is available.
The execution of these tasks are primarily the responsibility of the technical lead.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Infrastructure
Management Plan
(IFM.010)
The Infrastructure Management Plan documents the requirements needed to establish a technical infrastructure environment that is stable and
meets the project implementation requirements. It specifically provides the details for the Technical Infrastructure.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IFM030_PHYSICAL_RESOURCE_PLAN.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IFM.040 - MANAGE AND MAINTAIN INFRASTRUCTURE
In this task, monitor Infrastructure Management activities using the processes, procedures, controls and metrics defined in the Infrastructure Management Plan.
Examples include:
Ensure that all necessary software patches and hardware upgrades are applied in support of planned project activities.
Ensure that operational activities are occurring on a regular basis (e.g. backup, recovery, archiving, etc.).
Ensure that service levels are being met - especially infrastructure support service levels.
Report any issues or problems using established reporting procedures.
Ensure corrective action is taken.
Monitor effectiveness of corrective action.
This task is ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MMI Manage and Maintain Infrastructure
Back to Top
WORK PRODUCT
Maintained Infrastructure
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
Component
Description
1 Monitor infrastructure management activities using the metrics defined in the Infrastructure Management
Plan.
Metric Reports
2 Report any issues or problems using establish reporting procedures. Issue, Problem Log
Updates

3 Ensure corrective action is taken. Issue, Problem Log
Updates

4 Monitor effectiveness of corrective action. Metric Reports
Back to Top
APPROACH
The project manager is responsible for monitoring the metrics related to Infrastructure Management and reporting them to the project leadership. If the project manager
identifies any any issues or problems such as missed failure to apply patches as scheduled, backups not taken on schedule, etc., an issue or problem should be logged
using the appropriate procedure. The technical lead is responsible for the collection of base metrics, identification of suggested resolutions to issues or problems
encountered and ensuring that corrective actions are appropriately implemented.
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Infrastructure Management Plan
(IFM.010)
The Infrastructure Management Plan documents the processes, procedures and controls for managing the infrastructure
during the project.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
IFM040_EQUIPMENT_FAULT_RECORD.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
IFM.050 - CLOSE INFRASTRUCTURE
During Project Closure, the project manager is responsible for closing out Infrastructure Management. This includes the following responsibilities:
Perform final backup and archive of technical environment.
Remove all Oracle confidential information from client environment.
Turn over and document technical environment to client.
Revoke all access to client systems from Project Team Members.
Inventory and return any client owned assets, including software, supplies, office equipment, etc.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Infrastructure
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Perform final backup. Technical Environment Archive
2 Remove all Oracle confidential information. None
3 Turn over and document technical environment. Technical Environment Documentation
4 Revoke all access to client systems for project team members. Revoke Access
5 Inventory and return any client-owned assets. Return of Assets
Back to Top
APPROACH
This section is not yet available.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[PCM] PROCUREMENT MANAGEMENT
The Procurement Management process is focused on the following procurement tasks:
documenting the Procurement Strategy and Process
procuring any required goods and contracted services
managing the procurement of goods and services
The Procurement Strategy and Process determines whether to take a make-or-buy decision. It includes finding skilled people for the project (from the local office, from
the global company or external people to the company).
Procuring goods and services includes finding and deciding on one or more suppliers from the source above. Procuring contracted services includes setting up the
necessary contracts (i.e., contract administration).
The tasks above are normally managed by different roles in the organization.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
Typically, the project manager does not get involved in procurement activities except for acquiring human resources from outside firms (for example, Contract Service
Providers (CSPs)). Sub-contracted resources provide staff augmentation to the Oracle team. Normally, we use a CSP resource when qualified internal resources are
unavailable or to achieve a lower cost for our client. CSP firms have contracts with Oracle that include approved terms and conditions and pre-determined billing rates.
These agreements have been negotiated centrally by Oracle Consulting and should extend to all Oracle projects.
During Project Start Up, the project manager is responsible for documenting any procurement functions on the project in the Procurement Strategy and Process. This
includes documenting the roles and requirements of the procurement function and obtaining agreements from the key stakeholders.
Once the Financial Management Plan is in place, the project manager ensures that the procurement analyst(s) and buyer(s) understand the projects requirements for
subcontractors, hardware, network, application software configuration(s), etc.
Key aspects of procurement management are:
Analyzing requirements, negotiating and selecting suppliers (goods and/or services)
Ensuring scheduled deliveries
Project Execution and Control Phase
Following the Procurement Strategy and Process developed in the Project Start Up phase, the project manager is responsible for tracking, controlling and reporting on the
procurement status and expenditures.
Project Closure Phase
During Project Closure, the project manager is responsible for reconciling and closing out all open project procurement expenditures and providing a final planned versus
actual report.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS PCM.010 Develop Procurement Strategy and Process Procurement Strategy and Process Y Core
PS PCM.020 Procure Goods and Contracted Services Service Orders Core
Project Execution and Control
PEC PCM.030 Administer Procurement of Goods and Contracted Services Managed Procurement of Goods and Services Y Core
Project Closure
PC PCM.040 Close Contract Closed Contract Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager

Client (User)
CPS Client
Project
Sponsor

Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
PCM.010 - DEVELOP PROCUREMENT STRATEGY AND
PROCESS
Develop, document, and communicate the Procurement Strategy and Process. This may include the processes supporting the necessary procurement of goods and/or
services to support the project objectives. The Procurement Strategy and Process is a key component of the Project Management Plan.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Procurement Strategy and Process - The Procurement Strategy and Process documents the strategy and processes for supporting the necessary procurement of
goods and/or services to support the project objectives.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Identify procurement requirements. Procurement
Requirements
Document procurement requirements, such as:
Baseline hardware (along with an upgrade plan)
Network topology and scalability requirements
Third party software requirements
Subcontractor/services requirements
Project facilities
Off-site meeting facilities
Audio visual
2 Negotiate and establish a budget in support of agreed
upon purchasing requirements.
Purchasing Budget The budget should reflect the agreed upon categories and should be integrated
as part of the overall financial management process.
3 Define the procurement process. Procurement Process Document the procurement process from requisition to receipt of goods and
payment of invoice, including but not limited to:
Who purchases what (Oracle or the client)
Policies and procedures for rebilling purchases back to the client when
appropriate
Approval levels and lead times
Account numbers to be used for reporting purchases.
Rules pertaining to capital versus expense procurement
Situations when and how competitive bids must be obtained
Preferred vendor lists
Use of minority firms
4 Obtain key stakeholder agreement and approval on
the Procurement Strategy and Process.
Approved Procurement
Strategy and Process
Obtain any necessary sign-off or Approval Certificate.
5 Distribute and communicate the Procurement Strategy
and Process.
Procurement Strategy and
Process
File the plan for easy reference.
Back to Top
APPROACH
Considerations for Contracted Service Provider (CSP) Requirements: To make sure you get the exact skills you want, make sure you spell them out. Never assume that
everyone with particular skill also has an associated skill. Specify your expectations about the minimum experience (e.g., number of years, number of implementations)
required to be successful. Some requirements may be objective (must have successfully completed a specific course) or subjective (must have advanced knowledge
and experience with a given application). Every detail you add will help to communicate your needs to the CSP community and reduce the number of unqualified
candidates they propose.
Note: To maximize economies of scale and ensure that supplier lead times are honored, define procurement requirements as early in the project lifecycle as possible.
Note: It is also important that all procurement requirements are understood early to ensure timely delivery (and if necessary, installation and shake down) in order to
support critical project activities. Key dates and dependencies should be represented on the Project Workplan.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Procurement Management requirements that should be taken into
consideration when developing the Procurement Strategy and Process.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
PCM010_PROCUREMENT_STRATEGY_AND_PROCESS.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
PCM.020 - PROCURE GOODS AND CONTRACTED SERVICES
Procure goods and contracted services as they would apply to the project. The contracted services could include Oracle services or services from other sub-contracting
firms. The goods could include servers, other computer and telecommunications hardware, facilities, etc.
Care should be taken to confirm the correct approval levels and authorities when entering into a contract. The project manager should confirm and follow the appropriate
procedures for the given organization.
ACTIVITY
PS.ACT.EPI Establish Project Infrastructure
Back to Top
WORK PRODUCT
Service Orders
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Develop service orders for goods
and contracted services.
Prepare a description for the
service order.
Prepared
Service
Order
The Service Order description should contain enough detail to allow the potential suppliers to clearly understand
what you want them to accomplish. Keep in mind that your work description will be sent to service providers, so
avoid including sensitive information, like contract value and customer name. Constraints and assumptions should
be included as well.
Here is a short checklist of additional things to include in the service order:
description of what is out of scope when necessary for clarification
start date
end date
reporting requirements (for example, status, time, expense)
2 Request supplier responses, as
applicable.
Supplier
Responses
The potential suppliers do most of the work in this task by preparing the appropriate response to the service
order(s). Proposals should be prepared according to service order's directives and requirements. The proposal is
a legal document which represents the supplier's offer to the service order.
3 Select suppliers, as applicable. Selected
Suppliers
Review supplier responses and narrow down list of potential suppliers until final suppliers are selected.
4 Contract services, as applicable. Contract The contract reflects all agreements reached in terms of the services to be provided.
5 Order Goods, as applicable. Purchase
Orders
Purchase Orders
Back to Top
APPROACH
Considerations for Getting the Best Value from Contract Service Providers: Make sure you know the rate for each resource you are considering. Your goal is to get the
best resource at the lowest cost -- which may mean paying more per hour for someone who can get the job done faster. Availability should be a significant factor, too.
What is the impact to the project if the resource is unavailable on the date planned?
Having a carefully written Service Order can make the difference between a successful partnership and a failure. Make sure that everything you want the service provider
to do is in the Service Order. Remember, the Service Order drives the statement of work (SOW) and the SOW is the contractual link between the project and the service
provider, if it is wrong, the wrong result will be produced.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Procurement Strategy and Process
(PCM.010)
Use the process developed in the Procurement Strategy and Process to open service orders and procure goods and
services.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
PCM.030 - ADMINISTER PROCUREMENT OF GOODS AND
CONTRACTED SERVICES
This task is the administrative task for managing the procurement of goods and services based on the previously defined Procurement Strategy and Process. Both the
buyer and supplier participate in this task. Each party confirms that both it and the other party are meeting or have met their contractual obligations. They also make sure
their own legal rights are protected.
ACTIVITY
PEC.ACT.APGCS Administer Procurement of Goods and Contracted Services
Back to Top
WORK PRODUCT
Managed Procurement of Goods and Services
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Administer contract. Updated Contract
Records
Update the records to include supplier performance, payments, corrective action taken, any contract
amendments or contract terminations.
2 Receive goods and contracted
services.
Received Goods and
Services
Update the Financial Management Plan with payments. Update the Project Workplan.
Back to Top
APPROACH
This section is not yet available.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
#TOP #Top
Procurement Strategy and Process
(PCM.010)
Use the process developed in the Procurement Strategy and Process to administer service orders for goods and
services.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
PCM030_INCOMING_ITEM_RECORD.DOC MS WORD (Former PJM 2.6.1 template)
PCM030_REJECTION_NOTE.DOC MS WORD (Former PJM 2.6.1 template)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
PCM.040 - CLOSE CONTRACT
During Project Closure, all services and goods are inspected and verified to be acceptable. All necessary records are updated.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Closed Contract
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Close out all Requisitions, Purchase Orders, and Invoices. Closed Requisitions, Purchase Orders, and Invoices
2 Provide final reporting on Purchasing Budget and Supplier Performance. Final Purchasing Budget and Final Supplier Performance
Back to Top
APPROACH
This section is not yet available.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
None
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
PCM040_SUPPLIER_ASSESSMENT_RECORD.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Process Overview
Method Navigation Current Page Navigation
[OCHM] ORGANIZATIONAL CHANGE MANAGEMENT
As part of every project, it is important to address the technology, people, organizational and benefit needs in order to succeed through the entire lifecycle. If people and
organizational risks and benefits measurement are well managed, then the stakeholders are able to accept the change and realize the expected benefits of the new
technologies. With an efficient Change and Communication Plan, it is possible to create the change momentum needed to increase buy-in and reduce resistance - thus
reducing productivity losses.
Do not confuse this process with the Communication Management process. The Communication Management process focuses on the internal project team
communications to key stakeholders regarding progress and status while Organizational Change Management focuses on the broader set of communication typically
associated with the client organization.
Note: Do not confuse the Change and Communication Plan from this process with the Communication Plan created in the Communication Management process.
PROCESS FLOW
This section is not yet available.
Back to Top
APPROACH
Project Start Up Phase
During Project Start Up, the project manager is responsible for understanding the client's organizational change management and documenting that understanding in the
Client's Organizational Change Management Strategy. In addition, the project manager has to identify who will define the overall strategy for identifying and mitigating
organizational risks (culture, management and stakeholders reactions and organization model) and maximizing benefits throughout the lifecycle of the project. This
includes agreeing (with key stakeholders) on:
how to align the executives and management around the project and get their commitment
how to prepare the Oracle team and the client resources working efficiently together in a very short period of time
how to anticipate and manage stakeholders expectations/reactions during the project
how to identify the organizational and human risks that must be addressed during the project
how to communicate to all stakeholders and the clients customers/suppliers the changes related to the implementation
how to prepare the stakeholders to adapt to and adopt the new tasks
how to put in place the procedures to track and measure benefits
Project Execution and Control Phase
During Project Execution and Control, the Organizational Change Management process addresses the soft (human and organizational) part of the implementation by
increasing the stakeholders involvement and management commitment. This task prepares the organization and people for the implementation and increases their
ownership and participation in the success of the project. It also helps make the transition as smooth as possible by managing issues by target group (i.e., the people
who are most impacted by the change) at the right time with the right activities to support the change momentum.
Although, Oracle is not directly responsible, it is important for the Oracle project manager to stay aware of all the change management initiatives in order to anticipate
how stakeholders will react to the change. It is crucial to deploy the full change/communication plan and provide to the clients managers all the information regarding the
impacts on people. If a project manager is aware of political issues or stakeholders positive or negative reactions, it is very important to inform the change management
resources on the project. It is crucial before the go live date to check that stakeholders, managers and customers have received all the information and support that they
need to adopt the new technology.
Project Closure Phase
After the go live, the client has to manage peoples reactions to the changes. During the next few months, stakeholders will try to adapt themselves to their new tasks, new
procedures and work environment.
Back to Top
TASKS AND WORK PRODUCTS
The tasks and work products for this process are as follows:
Phase Task Work Product Key? Core/Opt
Project Start Up
PS OCHM.010 Understand Client's Organizational Change Management Strategy Client's Organizational Change Management Strategy Y Core
PS OCHM.020 Identify Change Management Warning Signs Change Management Warning Signs Core
Project Execution and Control
PEC OCHM.030 Execute Change and Communication Plan Executed Change and Communication Plan Y Core
Project Closure
PC OCHM.040 Establish Follow-Up Process Follow-Up Process Y Core
Back to Top
OBJECTIVES
This section is not yet available.
Back to Top
KEY RESPONSIBILITIES
The following roles are required to perform the tasks within this process:
Role
ID
Name Responsibility
Implementing Organization
PAD Project
Administrator
Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or task steps. If your
project does not have a dedicated project administrator, the project manager would perform these duties.
PM Project
Manager

Client (User)
CPS Client
Project
Sponsor

Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
OCHM.010 - UNDERSTAND CLIENT'S ORGANIZATIONAL
CHANGE MANAGEMENT STRATEGY
Organizational Change Management focuses on how the project solution is to be implemented into the organization. Its purpose is to substantially increase the likelihood
of successful project implementation by addressing the organizational and human aspect of the change. The project does not drive the Organizational Change
Management process in the organization, it is driven by the client or a third-party supplier. The client is solely responsible for the Organizational Change Management
process. Therefore, understanding the client's Organizational Change Management Strategy is critical to having a successful project implementation.
Document the strategy in the Client's Organizational Change Management Strategy. The Client's Organizational Change Management Strategy is a key component of the
Project Management Plan.
ACTIVITY
PS.ACT.VSSOS Validate Scope, Stakeholders and OCM Strategy
Back to Top
WORK PRODUCT
Client's Organizational Change Management Strategy - The Client's Organizational Change Management Strategy documents how the project solution is to be
implemented into the organization.
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Define the Client's
Organizational Change
Management Strategy
Overview of Client's
Organizational Change
Management Strategy
Document the PM's understanding of the Client's Organizational Change Management Strategy.
2 Define Change and
Communication Plan.
Change and Communication
Plan Overview
Document the plan to communicate to stakeholders external to the project. Refer to the
Communication Management process for guidance on developing communication plans.
3 Create Communication Matrix External Stakeholder
Communication Matrix
The Change and Communication Plan should consider all stakeholders external to the project
team, what will be communicated, the frequency of the communication, and how the
communication will occur.
4 Document Scheduled
Meetings
Scheduled Meetings Document when status/communication meetings will be held, i.e., every Thursday at 9:00 AM or
on some in frequent calendar. Include purpose, attendees, location, remote access, etc.
Back to Top
APPROACH
One challenge the project manager has is to align necessary changes caused by the project to the organization level, process level, and job level. In addition, the project
outcome needs to be aligned to the technical environment supporting the business in the organization.
A project has the potential to contribute significantly to the organization bottom line. The outcome of the project will also impact the way business is conducted. The effects
of the project outcome will also probably impact the overall customer satisfaction, the relationship with suppliers and the cycle time of core processes.
The project managers role is to get a committed sponsor who understands how the project will affect the organization. A committed sponsor will recognize the demand
that a project makes on organizational resources. The resolute sponsor will commit resources (change agents) who take the responsibility to facilitate the
implementation of the change. An effective network of cascading sponsorship down the organization improves the commitments of other stakeholders to support the
change throughout the organization.
A critical factor in succeeding with the project implementation is to manage resistance against the change caused by the project outcome in the organization. The project
manager can assist the sponsor by collecting the data necessary to indicate the ongoing levels of commitments necessary to sustain the change and report that to the
sponsor.
Organizational Change Management in projects includes the following activities:
#TOP #Top
Clarify the scope of the project Organizational Change Management work with the client.
Ensure the creation of an Organizational Change Management team at the client including sponsors and change agents.
Ensure that end-users/target groups are identified and plans are developed for training, communication, and end-user involvement.
Provide appropriate type and level of initial project Organizational Change Management actions to target groups and end-users to ensure commitment and
understanding of the change
Support the analysis of target groups and end-users ability to adapt the necessary change and their resistance levels.
Support the client in developing appropriate transition plans for each target group and end-user group.
Support the client in executing and monitoring the progress and issues.
Assist the client in evaluating the final result.
The Client's Organizational Change Management Strategy should identify the following roles:
What are the overall timeframes, milestones, tasks and key work products for the Organizational Change Management process.
Who will sponsor the project and put in place the Sponsorship Program to bring on board the management team?
Who will facilitate the Executive Alignment Workshop to align executives behind the project vision and objectives?
Who will identify the organizational risks and lead the Executive Execution Plan / Governance Rules (ENV.EOCM.020 and A.OCM.030)?
Who will facilitate the Team-Building Workshop to set the team rules, etc.?
Who will determine the benefit opportunity areas that drive the savings and ROI?
Who will define and set baselines for the metrics and develop the reports for tracking and measuring benefits?
Who will create and deploy the Change Management Roadmap / Communication Campaign (A.OCM.140) as well as other internal project communications that
address the managers'/stakeholders' expectations and concerns and generate a two-way communication to keep people involved and knowledgeable regarding
the changes? The Change Management Roadmap / Communication Campaign includes activities and a two-way communication initiative organized by audience,
expectations, issues, speaker, and preferred communication channels to ensure that the right information is communicated to the right people using the right
vehicle at the right time.
Who will conduct the job impact analysis on the roles, organizational environment, workflow and necessary inputs to the HR policies and training plans.
Who is responsible for the development of a training strategy and plan for delivery of training?
If these roles are not identified in the Client's Organizational Change Management Strategy, the project manager should document this as a risk and bring it to the
attention of the project sponsor and Steering Committee.
Tip: Review the Organizational Change Management (OCM) process in the Implement Focus Area to ensure a correlation between the Client's Organizational Change
Management Strategy and the OCM process, activities, tasks and work products.
Back to Top
SUPPLEMENTAL GUIDANCE
Oracle Support Services
This task has supplemental guidance that should be considered for Oracle Support Services. Use the following to access the task-specific supplemental guidance. To
access all application implementation supplemental information, use the OUM Oracle Support Services Supplemental Guide.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Project Management
Framework (BT.070)
The Project Management Framework contains any high-level Organizational Change Management Management requirements that should be
taken into consideration when developing the detailed Organizational Change Management Strategy.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
OCHM010_CLIENTS_ORGANIZATIONAL_CHANGE_MANAGEMENT_STRATEGY.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
OCHM.020 - IDENTIFY CHANGE MANAGEMENT WARNING
SIGNS
The project manager should monitor stakeholders' participation and attitude during the Start Up phase, and throughout the project lifecycle, to identify problems that can
arise as a result of ineffective organization change management. A stakeholder with a personal agenda could potentially cause a project to fail. Being proactive in this
area by continually communicating with all stakeholders decreases the likelihood that such a situation will occur.
ACTIVITY
PS.ACT.CPMP Complete Project Management Plan
Back to Top
WORK PRODUCT
Change Management Warning Signs
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component
Component
Description
1 Flag quickly any deviation in the Client's Organizational Change Management Strategy and
raise it to the stakeholders as a risk.
Client's Organizational Change Management
Strategy Deviations

2 Monitor stakeholders' participation and attitude during the Project Start Up phase. Stakeholders' Participation
3 Recognize and document any project risk related to people and /or organizational culture. Organizational Change Management Project
Risks

4 Consider as real and certain any constraint that has already been identified by the project
team.
Organizational Change Management Project
Constraints

Back to Top
APPROACH
The key to surviving change is to help all individuals become aligned with the vision and understanding the reason for the change. Understanding the factors that drive
change, and how people react to it is an important first step to early identify change management warning signs.
Finding a customer or partner who understands the underlying principles of change, and uses them to develop comprehensive change management framework can help
ensure the success of the project. Because this is a soft work product in a project, it can often be overlooked, or minimized in importance.
Business processes associated with new software (and the leading practices that go with it) can spell significant change to the systems users and the project manager
should identify these areas a project risks. The project manager keeps abreast of progress in this area in order to assess impact to the project timeframe's and work
products.
Items to recognize as change management warning signs include:
a high level of stakeholder reactions
difficulty in gaining sponsorship and/or obtaining business resources
misunderstandings about project expectations around scope, vision and/or objectives
low attendance at meetings, functions, etc.
difficulty in identifying and/or measuring benefits or tangible objectives for the project
existence of unplanned activities surrounding change management and/or benefits tracking
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Client's Organizational Change Management Strategy (OCHM.010) Review the Client's Organizational Change Management Strategy to identify warning signs/risks.
Back to Top
TEMPLATES AND TOOLS
The following templates and tools are available to assist with this task:
Template File Name Comments
OCHM020_CHANGE_MANAGEMENT_WARNING_SIGNS.DOC MS WORD
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
OCHM.030 - EXECUTE CHANGE AND COMMUNICATION PLAN
Execute the Change and Communication Plan that was developed as part of the Organizational Change Management Strategy. At a minimum, know how the change and
communication activities will be deployed and aligned with project milestones. Be aware of the key messages being communicated to users, customers, etc. This task is
ongoing throughout the Project Execution and Control phase.
ACTIVITY
PEC.ACT.MCOP Manage Communications and OCM Plans
Back to Top
WORK PRODUCT
Executed Change and Communication Plan
Back to Top
TASK STEPS
You should follow these steps:
No. Task Step Component Component Description
1 Execute the Change and Communication Plan. None Communicate with external stakeholders based on the
guidelines and frequency outlined in the Change and
Communication Plan.
2 Review Organizational Change Management Strategy, including the
Change and Communication Plan with project stakeholders on a
periodic basis.
Updated Organizational
Change Management
Strategy.
Update the document, as required.
Back to Top
APPROACH
Confirm with accepting organization's project manager that the Organizational Change Management Strategy includes a plan to communicate to stakeholders external to
the project. This Change and Communication Plan should consider all stakeholders external to the project team, what will be communicated, the frequency of the
communication, and how the communication will occur.
The Organization Change Management team must anticipate and plan for changes affecting anyone in the organization or outside the organization who is impacted by the
new system. Often, the entire organization is affected. An example would be a payroll implementation that changes the look and feel of paychecks. Another example
would be a new system that will provide the consumer with the ability to order product on-line. Such an endeavor requires coordination between many business
departments and can take months to finalize. Review change information for potential impact to the overall training and work plans.
Business process change management involves anticipating and planning for changes in the way people do their jobs. If someone's day-to-day job processes are altered
by the new system, the business process change management plan should address it.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or
repetitive activities, tasks or task steps. If your project does not have a dedicated project
administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Client's Organizational Change Management Strategy
(OCHM.010)
Execute the Communication Plan documented in the Organizational Change Management Strategy.
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Task Overview
Method Navigation Current Page Navigation
OCHM.040 - ESTABLISH FOLLOW-UP PROCESS
During Project Closure, confirm with the client that a process is in place to review the progress of Organizational Change Management activities and determine if any
actions need to be taken to alter the strategy. Assess risk of deviations from the Client's Organizational Change Management Strategy and the potential affect to project.
ACTIVITY
PC.ACT.CPC Close Processes and Contracts
Back to Top
WORK PRODUCT
Follow-Up Process
Back to Top
TASK STEPS
This section is not yet available.
Back to Top
APPROACH
This section is not yet available.
Back to Top
ROLES AND RESPONSIBILITIES
This task involves the following project roles:
Role Responsibility %
Project Administrator Assist the project manager in the day-to-day management of the project by performing routine or repetitive activities, tasks or
task steps. If your project does not have a dedicated project administrator, the project manager would perform these duties.
15
Project Manager 85
Client Project Sponsor *
* Participation level not estimated.
Back to Top
PREREQUISITES
You need the following for this task:
Prerequisite Usage
Client's Organizational Change Management Strategy (OCHM.010)
Back to Top
TEMPLATES AND TOOLS
There are currently no templates available to assist with this task.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Focus Area Overview
Method Navigation Current Page Navigation
ENVISION
INTRODUCTION
Envision comprises the areas of the Oracle Unified Method framework that deal with development and maintenance of enterprise level IT strategy, architecture, and
governance. Ideally, every enterprise should be executing these or similar processes. Every project that effects a corporation's IT landscape should have its origins here.
The goals for Envision are to:
Provide a set of processes that can be adopted by an enterprise in order to better align IT delivery with Business strategy.
Provide a framework for development of services for enterprise or strategic level interactions.
Provide the context for OUM based delivery services and connect those services to the larger IT lifecycle.
Indeed, one of the goals of OUM is to provide the methodological basis for the delivery of any IT related service. Envision extends OUM's capabilities beyond delivery
and management of software implementation projects into the realm of IT vision and strategy. Like many of aspects of OUM, it is not likely that all of Envision's processes
and tasks will be executed within any single enterprise, nor is it likely that Envision will ever contain an exhaustive set of enterprise level processes. Rather, Envision
should serve as a framework that can be scaled to suit the needs of a particular enterprise.
Envision is focused on information technology related business architecture and practices. The following is a list of the objectives of Envision:
Provide the vision for one or more projects intended to realize a focused set of business objectives
Establish or bolster a broad set of enterprise level IT processes that are to be continued
Define an enterprise "Strategy" on such topics as Governance, Business Intelligence, or Business Process improvement, prior to an OUM project that supports
implementation of specific technology in these areas
Respond to critical business needs or pain points
The diagram below shows how Envision relates to the other focus areas of the Oracle Unified Method. The diagram reflects the influence that Envision work has on OUM
delivery and management of OUM implementation projects (Implement focus area). Envision work may precede one or more IT Projects. Envision need not end when an
OUM delivery project starts, but spans the whole project lifecycle of current and future IT projects instead. The following picture illustrates the ongoing nature of Envision:
In future releases, Envision will become more complete and better integrated with the rest of the OUM framework. We will establish a stronger symbiosis between
Envision tasks and the OUM delivery tasks that are being executed to realize specific portions of the enterprise strategy. In general, any service that is focused at the
enterprise level or on strategic business objectives should be based on some combination of Envision tasks.
Back to Top
PHASES
Envision currently has two phases:
Initiate
Maintain and Evolve
During Initiate, you perform a set of foundational tasks. Those tasks have a broad range of objectives and applicability. At one end, delivering a service based on the
Envision Roadmap process can establish the vision for one or more projects intended to realize a focused set of business objectives (e.g., Roadmap to SOA). On the
other end, Initiate phase processes can be used to establish a broad set of enterprise level IT processes that are continued in the Maintain and Evolve phase.
The processes and tasks of the Maintain and Evolve phase bring the work begun during Initiate into the day to day life of the enterprise. This phase forms the foundation
for governing and managing enterprise level business processes and strategies. Envision is not intended to be a broad treatise on corporate strategic planning. It is
focused on information technology related business architecture and practices. Some enterprises may adopt these processes in whole or part. They should also form the
basis for defining service offerings. At the very least, they are intended to provide architects and practitioners with an evolving set of leading practices around Enterprise
Business Analysis, Enterprise Architecture, IT Strategy, and IT Portfolio Management.
Finally, Initiate-based services or sets of tasks may also be performed periodically. These may be required to develop further detail on specific objectives or to respond to
critical business needs or pain points that bubble up out of Maintain and Evolve tasks.
Back to Top
KEY CONCEPTS
One of the key concepts in understanding the Envision focus area is to see the relationship between an Envision project and how any subsequent implementation projects
make use of the artifacts from an Envision based project.
Envision projects produce the following types of artifacts:
Data and Information Models
Distributed Services Designs
Recommendations on Hardware & Software Components
Platform Configuration Designs
Operating Infrastructure Designs and Implementations
Selection of Applications and Systems Support Tools
Operations Infrastructure Strategies
The implementation projects in return provide:
Validation of Technical Designs
Exposure of Areas Requiring Further Work or Research at the Enterprise level
Value to the Enterprise through implementations that support the Business Objectives and Requirements
One other key concept is that Envision Projects are done at the Enterprise level, but do not always look at the entire enterprise at once. In some cases, proof of concept is
done to test a particular recommendation or strategy, and at the same time, solve a particular business problem for an area within the Enterprise.
Back to Top
PROCESSES
The overall organization of OUM is expressed by a process-based system engineering methodology.
A process is a cohesive set or thread of related tasks that align to a specific project objective. A process results in one or more key outputs. Each process is a discipline
that usually involves similar skills to perform the tasks within the process. You might think of a process as a simultaneous sub-project or workflow within a larger
development project.
This section describes the key OUM Envision processes.
[ER] Envision Roadmap Process
[BA] Enterprise Business Analysis Process
[OCM] Organizational Change Management Process
[EA] Enterprise Architecture Process
[IP] IT Portfolio Management Process
[GV] Governance Process
[ER] Envision Roadmap Process
The Envision Roadmap process accelerates project implementations by focusing on the key strategic and tactical areas that must be addressed in order to maximize the
Enterprise's return on investment, while minimizing the business risk in order to successfully complete a project.
[BA] Enterprise Business Analysis Process
The Enterprise Business Analysis process provides analysis of the enterprise-level requirements and sets up the business boundaries of the OUM project. It produces a
set of requirements models of the enterprise, such as enterprise process models, domain models and use case models.
[OCM] Organizational Change Management Process
The Organizational Change Management process starts at the strategic level with executives and then identifies the particular human and organizational challenges of the
technology implementation in order to design a systematic, time-sensitive, and cost-effective approach to lowering risk that is tailored to each organizations specific
needs. In addition to increasing user adoption rates, carefully planning for and managing change in this way allows organizations to maintain productivity through often-
difficult technological transitions. This in turn enables the organization to more easily meet deadlines, realize business objectives, and maximize return on investment.
[EA] Enterprise Architecture Process
Enterprise Architecture covers an enterprise-level view on both the application and technical architecture of the systems.
[IP] IT Portfolio Management Process
IT Portfolio Management covers a holistic view of the overall IT strategy of the enterprise. Its main purpose is to validate that IT projects are aligned with the corporate
strategy by maximizing the investment in IT projects while minimizing the risks.
[GV] Governance Process
In the Governance process you review the organizations strategies and objectives and affirm that the IT related objectives and strategies fit within those of the
organization. A well-defined Governance process should validate that the IT investments are aligned with the business strategies throughout the enterprise, and mitigate
associated risks.
Back to Top
ACTIVITIES
Envision tasks are further refined into activities to better represent the Envision lifecycle.
As part of OUM, Envision also uses the Unified Process (UP). UP is an iterative and incremental approach to developing and implementing software systems. Therefore,
any activity (and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable.
Activities may be iterated to either increase the quality of the activity or task outputs to a desired level, to add sufficient level of detail, or to refine and expand them on the
basis of user feedback.
Within the Envision phases, the following major activities have been identified:
Initiate Phase Activities
Prepare Envision Foundation
Prepare for Discovery
Conduct Executive Alignment Workshop - Envision
Define and Maintain Common Enterprise Concepts
Execute Discovery - Gather Information (As Is)
Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
Execute Discovery - Finish
Develop Solution and Present to Client
Plan Transition to Implementation
Maintain and Evolve Phase Activities
Maintain and Evolve
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
MANAGEMENT
OUM uses the Manage focus area. You should read the Manage focus area overview to gain a better understanding of this focus area.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[INIT] INITIATE
During Initiate, you perform a set of foundational tasks. Those tasks have a broad range of objectives and applicability. At one end, delivering a service based on the
Envision Roadmap process can establish the vision for one or more projects intended to realize a focused set of business objectives (for example, Roadmap to SOA). On
the other end, Initiate phase processes can be used to establish a broad set of enterprise level IT processes that are continued in the Maintain and Evolve phase.
Finally, initiate-based services or sets of tasks may also be performed periodically. These may be required to develop further detail on specific objectives or to respond to
critical business needs or pain points that bubble up out of Maintain and Evolve phase tasks.
This phase overview is written from the perspective of a Full Method View, utilizing ALL of the processes, activities and tasks in this phase. Therefore, all of the following
sections provide comprehensive information. If your project is utilizing a tailored approach (for example, Technology Full Lifecycle View, Application Implementation View,
Middleware Architecture View), not everything in this overview may be appropriate for your project. Please keep this in mind, especially when reviewing the Prerequisites,
Processes, Key Work Products, Tasks and Work Products and Task Dependencies sections. You should use OUM as a guideline for performing all types of information
technology projects, but keep in mind that every project is different and that you need to adjust project activities according to each situation. Do not hesitate to add,
remove, or rearrange tasks, but be sure to reflect these changes in your estimates and risk management planning. You should also consider the depth to which you
address and complete each task based on the characteristics of your particular project or project increment. See Oracle's Full Lifecycle Method for Deploying Oracle-
Based Business Solutions for further information on the scalability and adaptability of OUM.
Back to Top
OBJECTIVES
The following is a list of the objectives of this phase:
Provide the vision for one or more projects in order to achieve a focused set of business objectives
Establish or bolster a broad set of enterprise level IT processes that are to be continued
Define an enterprise "Strategy" on such topics as Governance, Business Intelligence, or Business Process improvement, prior to an OUM project that supports
implementation of specific technology in these areas
Respond to critical business needs or pain points
Back to Top
PROCESSES
The following processes are active in this phase:
Envision Roadmap (ER)
Enterprise Business Analysis (BA)
Organizational Change Management (EOCM)
Enterprise Architecture (EA)
IT Portfolio Management (IP)
Governance (GV)
Back to Top
KEY WORK PRODUCTS
This section is not yet available.
Back to Top
TIPS AND TECHNIQUES
This section is not yet available.
Back to Top
TASKS AND WORK PRODUCTS
Envision includes the following tasks:
ID Task Work Product
#TOP #TOP
Envision Roadmap
ER.010 Create Business Case for Envision Enagement Customer Envision Engagement Strategy
ER.015 Conduct Enterprise Maturity Assessment Maturity Analysis and Recommendations Report
ER.020 Determine Envision Engagement Strategy Envision Engagement Strategy
ER.025 Educate Enterprise on Area of Focus Educated Enterprise
ER.030 Set and Agree on Plan for Envision Engagement Envision Engagement Plan
ER.040 Research Enterprise Enterprise Research Findings
ER.045 Establish Executive Sponsorship Committed Executive Sponsorship
ER.050 Validate and Agree on Envision Engagement Plan Agreed on Envision Engagement Plan
ER.070 Define Modeling Strategy for the Enterprise Enterprise Modeling Strategy
ER.080 Obtain Existing Reference Material Existing Reference Material
ER.090 Conduct Solution Readiness Assessment Solution Readiness Assessment
ER.100 Define Supplemental Enterprise Requirements Supplemental Enterprise Requirements
ER.110.1 Perform Benefit Analysis Benefit Analysis
ER.110.2 Perform Benefit Analysis Benefit Analysis
ER.120.1 Identify and Mitigate Future State Risks Future State Risks
ER.130.1 Produce MoSCoW Improvement List MoSCoW Improvement List
ER.140 Share Product Strategies with Enterprise Informed Enterprise
ER.150 Review Discovery Findings Reviewed Discovery Findings
ER.160 Develop Desired Future State Desired Future State
ER.165 Identify Capability Challenges Current Capability Challenges
ER.167 Determine Remediation Approaches Remediation Approaches
ER.170 Develop Future State Transition Plan Future State Transition Plan
ER.180 Prepare for and Present Solution Recommendation Solution Recommendations
ER.190 Review Business Feedback and Identify Opportunities Opportunities Task List
ER.200 Prepare for Transition to Sales or Services Opportunities Action Plan
Enterprise Business Analysis
BA.010 Identify Business Strategy Business Strategy
BA.012 Define Business Scope Business Scope
BA.015 Conduct Enterprise Stakeholder Assessment Enterprise Stakeholder Inventory
BA.017.1 Determine Metrics Collection and Reporting Strategy Metrics Collection and Reporting Strategy
BA.018.1 Establish Current Baseline Metrics Current Baseline Metrics
BA.020 Document Enterprise Organization Structures Enterprise Organization Structures
BA.025 Determine Operating Model Validated Operating Model
BA.030.1 Develop Enterprise Glossary Enterprise Glossary
BA.040 Create Enterprise Function or Process Model Function or Enterprise Process Model
BA.045 Develop Enterprise Business Context Diagram Enterprise Business Context Diagram
BA.050 Develop Enterprise Domain Model (Business Entities) Enterprise Domain Model
BA.055 Develop Enterprise Knowledge Flow Enterprise Knowledge Flow
BA.058 Develop Business Architecture Business Architecture
BA.060.1 Perform High-Level Use Case Discovery High-Level Use Cases
BA.060.2 Perform High-Level Use Case Discovery High-Level Use Cases
BA.065 Review Busines IT SLA Business-IT SLA Report
BA.067 Review Business Volumetrics Business Volumetrics Report
BA.070 Identify Candidate Services Service Portfolio - Candidate Services
BA.080 Identify Candidate Enterprise Business Rules Candidate Business Rules
BA.090 Identify Process Improvement Options Process Improvement Options
Organizational Change Management
EOCM.010 Create and Manage Ad Hoc Communications Ad Hoc Communications
EOCM.020 Prepare for Executive Alignment Workshop Executive Alignment Workshop Materials
EOCM.030 Conduct Executive Alignment Workshop Executive Business Objectives and Governance Rules
EOCM.040 Build and Deploy Sponsorship Program Sponsorship Program
EOCM.050 Assess Enterprise Change Readiness Preliminary Enterprise Change Management Assessment
EOCM.060 Prepare Project Team for Enterprise Culture Prepared Project Team
EOCM.070 Identify Change Agent Structure Change Agent Structure
Enterprise Architecture
EA.001 Justify and Engage Enterprise Architects Assigned Enterprise Architect
EA.002 Review External Reference Architectures External Reference Architectures Review
EA.010.1 Review Architecture Principles, Guidelines and Standards Architecture Principles, Guidelines and Standards
EA.030 Identify Current Enterprise Architecture Current Enterprise Architecture
EA.040 Analyze Capabilities Capabilities Model
EA.050 Identify Current Architectural Challenges Current Architectural Challenges
EA.057 Review Business Capacity Plan Business Capacity Plan
EA.060 Identify Architectural Gaps and Improvement Options Architectural Gaps and Improvement Options
EA.065 Identify Enterprise IT Strategy Enterprise IT Strategy
EA.075 Develop Technology Reference Architectures Technology Reference Architectures
EA.095 Review Enterprise Software Development Process Enterprise Software Development Process
EA.110 Develop Future State Enterprise Architecture Future State Enterprise Architecture
EA.120 Develop Information Architecture Information Architecture
EA.130 Develop Technology Architecture Technology Architecture
EA.140 Develop Applications Architecture Applications Architecture
EA.150 Define Transitional Architectures Transitional Architectures
EA.160 Define Business Rules Implementation Strategy Business Rules Implementation Strategy
EA.170 Identify Integration Requirements Integration Requirements
EA.190 Define Product Implementation Prioritization Product Implementation Prioritization Report
EA.200 Determine Development Framework and Policy Guidelines Development Framework
IT Portfolio Management
IP.010 Inventory Projects IT Project Portfolio
IP.012 Inventory Applications IT Application Portfolio
IP.014 Inventory Services Service Portfolio
IP.015 Conduct Portfolio Analysis Portfolio Analysis Report
IP.020 Analyze Services Service Portfolio - Proposed Services
IP.025 Populate Services Repository Populated Services Repository
IP.030 Analyze Business Rules Business Rules Analysis
IP.040 Identify Candidate Projects Candidate Projects
IP.050.1 Prioritize Projects Prioritize Projects
IP.060 Develop IT Portfolio Plan IT Portfolio Plan
Governance
GV.010 Define Governance Strategy Governance Strategy
GV.015 Review Current Governance Model Current Governance Model
GV.020.1 Determine Regulatory and Business Mandates Mandate Matrix
GV.030.1 Discover or Define Policies Governance Policies Catalog
GV.040 Determine Organizational Impact of Governance Impact Study and List of Proposed Organizational Changes
GV.050.1 Define Policy Implementation Processes Policy Implementation Processes
GV.060.1 Define Policy Implementation Tooling Governance Policy Tooling
GV.070.1 Define Policy Metrics Measurements Portfolio
GV.080.1 Define Policy Monitoring Processes Policy Monitoring Processes
GV.090.1 Determine Funding Model Funding Model
GV.092 Determine Projects Meta Data Description Projects Meta Data Description
GV.094 Determine Applications Meta Data Description Applications Meta Data Description
GV.096 Determine Services Meta Data Description Services Meta Data Description
GV.098 Determine Other Meta Data Descriptions Other Meta Data Descriptions
GV.100.1 Implement Governance Governance Implementation
Back to Top
ACTIVITY FLOW DIAGRAM
Back to Top
MANAGING RISK
This section is not yet available.
Back to Top
CRITICAL SUCCESS FACTORS
This section is not yet available.
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.PEF - PREPARE ENVISION FOUNDATION
This activity focuses on prepare the foundation for the Envision engagement, such as creating the Business Case, justifying and engaging enterprise architects,
establishing the executive sponsorship, documenting the organization structures, determining engagement strategies and defining the Business Scope.
Back to Top
OBJECTIVES
The objective for this activity is provide the foundation for the Envision engagement.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
ER.010 Create Business Case for Envision Engagement
EA.001 Justify and Engage Enterprise Architects
ER.040 Research Enterprise
ER.045 Establish Executive Sponsorship
BA.010 Identify Business Strategy
BA.012 Define Business Scope
BA.015 Conduct Enterprise Stakeholder Assessment
GV.010 Define Governance Strategy
BA.017.1 Determine Metrics Collection and Reporting Strategy
BA.018.1 Establish Current Baseline Metrics
BA.020 Document Enterprise Organization Structures
BA.025 Determine Operating Model
EA.002 Review External Reference Architectures
ER.015 Conduct Enterprise Maturity Assessment
ER.020 Determine Envision Engagement Strategy
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to execute the tasks and develop the work products with the assistance of the client stakeholders.
Back to Top
PREREQUISITES
You will need the following for this activity:
PS.ACT.RBAC Review Bid and Contract
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.PD - PREPARE FOR DISCOVERY
This activity focuses on creating and managing Ad Hoc Communications, educating the enterprise and setting the plan for the Envision engagement.
Back to Top
OBJECTIVES
The objective for this activity is to validate and agree on the Envision engagement.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
EOCM.010 Create and Manage Ad Hoc Communications
ER.025 Educate Enterprise on Area of Focus
ER.030 Set and Agree on Plan for Envision Engagement
ER.050 Validate and Agree on Envision Engagement Plan
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to create and manage Ad Hoc Communications, educate the enterprise on any appropriate areas of focus and set, validate and agree on
the Envision Engagement Plan.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.PEF Prepare Envision Foundation
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.CEAWE - CONDUCT EXECUTIVE ALIGNMENT
WORKSHOP - ENVISION
This activity focuses on preparing and conducting the Executive Alignment Workshop and building and deploying the Sponsorship Program at the enterprise level.
Back to Top
OBJECTIVES
The objective for this activity is to capture the decisions made about enterprise vision, objectives, and success criteria in order to communicate them to the enterprise so
that they can then provide direction to middle managers and end users. During this activity, the executives will commit to modeling the change as they work to build and
deploy the Sponsorship Program.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
EOCM.020 Prepare for Executive Alignment Workshop
EOCM.030 Conduct Executive Alignment Workshop
EOCM.040 Build and Deploy Sponsorship Program
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to prepare the materials for and conduct the Executive Alignment Workshop and build and deploy the Sponsorship Program.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.PD Prepare for Discovery
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.DMCEC - DEFINE AND MAINTAIN COMMON
ENTERPRISE CONCEPTS
In this activity, you develop, review and define the Enterprise Glossary, Enterprise Architecture Principles, Guidelines and Standards and Enterprise Modeling Strategy.
Back to Top
OBJECTIVES
The objective for this activity is to establish and maintain work products that provide standards for the enterprise.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
BA.030.1 Develop Enterprise Glossary
EA.010.1 Review Architecture Principles, Guidelines and Standards
ER.070 Define Modeling Strategy for the Enterprise
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to develop the work products and maintain them as appropriate.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.PEF Prepare Envision Foundation
INIT.ACT.PD Prepare for Discovery
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.EDGI - EXECUTE DISCOVERY - GATHER
INFORMATION (AS IS)
The focus of this activity is to gather information about the enterprise.
Back to Top
OBJECTIVES
The objective for this activity is determine a realistic current state assessment of the enterprise.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
EOCM.050 Assess Enterprise Change Readiness
EOCM.060 Prepare Project Team for Client Culture
EOCM.070 Identify Change Agent Structure
ER.080 Obtain Existing Reference Material
ER.090 Conduct Solution Readiness Assessment
GV.015 Review Current Governance Model
GV.020.1 Determine Regulatory and Business Mandates
BA.040 Create Enterprise Function or Process Model
BA.050 Develop Enterprise Domain Model (Business Entities)
BA.055 Develop Enterprise Knowledge Flow
BA.058 Develop Business Architecture
BA.060.1 Perform High-Level Use Case Discovery
EA.030 Identify Current Enterprise Architecture
EA.040 Analyze Capabilities
GV.030.1 Discover or Define Policies
EA.050 Identify Current Architectural Challenges
GV.092 Determine Projects Meta Data Description
IP.010 Inventory Projects
GV.094 Determine Applications Meta Data
IP.012 Inventory Applications
IP.015 Conduct Portfolio Analysis
BA.065 Review Business-IT SLA
BA.067 Review Business Volumetrics
GV.096 Determine Services Meta Data Description
IP.014 Inventory Services
GV.098 Determine Other Meta Data Descriptions
ER.100 Define Supplemental Enterprise Requirements
EA.057 Review Business Capacity Plan
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to execute the tasks. This may include actually developing the work products or simply gathering already existing documents from the
enterprise.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.PEF Prepare Envision Foundation
INIT.ACT.PD Prepare for Discovery
INIT.ACT.CEAWE Conduct Executive Alignment Workshop - Envision
INIT.ACT.DMCEC Define and Maintain Common Enterprise Concepts
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.EDBPD - EXECUTE DISCOVERY - BRAINSTORM,
PRIORITIZE AND DISCOVER ENTRY POINTS
In this activity, you analyze, develop and prioritize opportunities to improve the enterprise.
Back to Top
OBJECTIVES
The objective for this activity is to identify, analyze and prioritize opportunities to improve the enterprise.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
BA.045 Develop Enterprise Business Context Diagram
GV.040 Determine Organizational Impact of Governance
EA.060 Identify Architectural Gaps and Improvement Options
EA.065 Identify Enterprise IT Strategy
ER.110.1 Perform Benefit Analysis
BA.060.2 Perform High-Level Use Case Discovery
EA.075 Develop Technology Reference Architectures
BA.070 Identify Candidate Services
IP.020 Analyze Services
IP.025 Populate Services Repository
BA.080 Identify Candidate Enterprise Business Rules
IP.030 Analyze Business Rules
BA.090 Identify Process Improvement Options
ER.120.1 Identify and Mitigate Future State Risks
ER.130.1 Product MoSCoW Improvement List
EA.095 Review Enterprise Software Development Process
IP.040 Identify Candidate Projects
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to identify architectural gaps and improvement options and process improvement options and then do some analysis on how to improve the
enterprise by addressing those options.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.PEF Prepare Envision Foundation
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.EDF - EXECUTE DISCOVERY - FINISH
This activity focuses on sharing and reviewing discovery findings with the enterprise.
Back to Top
OBJECTIVES
The objective for this activity is to inform the enterprise of all the findings and improvement options defined up to this point to determine how to proceed further.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
ER.140 Share Product Strategies with Enterprise
ER.150 Review Discovery Findings
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to review the solution options with the enterprise. You should include a comprehensive list of findings and a preliminary assessment of
priorities.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.DSPC - DEVELOP SOLUTION AND PRESENT TO
CLIENT
The focus of this activity is to develop, prepare and present to the enterprise any necessary documentation to communicate the engagement solution.
Back to Top
OBJECTIVES
The objective for this activity is to communicate the solution to the enterprise.
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
GV.050.1 Define Policy Implementation Processes
GV.060.1 Define Policy Implementation Tooling
GV.070.1 Define Policy Metrics
GV.080.1 Define Policy Monitoring Processes
GV.090.1 Determine Funding Model
GV.100.1 Implement Governance
ER.160 Develop Desired Future State
ER.165 Identify Capability Challenges
ER.167 Determine Remediation Approaches
EA.110 Develop Future State Enterprise Architecture
EA.120 Develop Information Architecture
EA.130 Develop Technology Architecture
EA.140 Develop Applications Architecture
EA.150 Define Transitional Architectures
EA.160 Define Business Rules Implementation Strategy
ER.170 Develop Future State Transition Plan
EA.170 Identify Integration Requirements
IP.050.1 Prioritize Projects
ER.110.2 Perform Benefit Analysis
IP.060 Develop IT Portfolio Plan
EA.190 Define Product Implementation Prioritization
ER.180 Prepare for and Present Solution Recommendations
EA.200 Define Development Framework and Policy Guidelines
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to define and prepare and implement any necessary Governance. Next, document the desired future state, any challenges and the
preferred approach to mitigating those challenges. An overall Future State Enterprise Architecture is developed along with documenting the the architecture for
Information, Technology and Applications. A Transition Plan is developed with projects for moving towards the future state from the current state. Projects are identified,
analyzed and prioritized.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.EDGI Execute Discovery - Gather Information (As Is)
INIT.ACT.EDBPD Execute Discovery - Brainstorm, Prioritize and Discover Entry Points
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Activity Overview
Method Navigation Current Page Navigation
INIT.ACT.PTI - PLAN TRANSITION TO IMPLEMENTATION
The focus of this activity is to review business feedback and identify opportunities that could result in an implementation project.
Back to Top
OBJECTIVES
The objective for this activity is to transition from an Envision engagement to an implementation project(s).
Back to Top
TASKS
The tasks included in this activity are:
ID Task Name
ER.190 Review Business Feedback and identify Opportunities
ER.200 Prepare for Transition to Sales or Services
Back to Top
ITERATIONS
OUM is Oracle's approach to Unified Process. UP is an iterative and incremental approach to developing and implementing software systems. Therefore, any activity
(and its tasks) may be iterated. Whether or not to iterate, as well as the number of iterations (times the activity is repeated) within an increment, are variable. Activities
may be iterated to either increase the quality of the work products to a desired level, to add sufficient level of detail, or to refine and expand them on the basis of user
feedback.
Back to Top
APPROACH
The approach to this activity is to review business feedback and identify potential opportunities for implementation projects.
Back to Top
PREREQUISITES
You will need the following for this activity:
INIT.ACT.DSPC Develop Solution and Present to Client
Back to Top
Copyright 2006, 2014, Oracle and/or its affiliates. All rights reserved.
OUM 6.2 Phase Overview
Method Navigation Current Page Navigation
[ME] MAINTAIN AND EVOLVE
The processes and tasks of the Maintain and Evolve phase bring the work begun during Initiate into the day to day life of the enterprise. This phase forms the foundation
for governing and managing enterprise level business processes and strategies. Envision is not intended to be a broad treatise on corporate strategic planning. It is
focused on information technology related business architecture and practices. Some enterprises may adopt these processes in whole or part. They should also form the
basis for defining service offerings. At the very least, they are intended to provide architects and practitioners with an evolving set of leading practices around Enterprise
Business Analysis, Enterprise Architecture, IT Strategy, and IT Portfolio Management.
Finally, Initiate-based services or sets of tasks may also be performed periodically. These may be required to develop further detail on specific objectives or to respond to
critical business needs or pain points that bubble up out of Maintain and Evolve tasks.
This phase overview is written from the perspective of a Full Method View, utilizing ALL of the processes, activities and tasks in this phase. Therefore, all of the following
sections provide comprehensive information. If your project is utilizing a tailored approach (for example, Technology Full Lifecycle View, Application Implementation View,
Middleware Architecture View), not everything in this overview may be appropriate for your project. Please keep this in mind, especially when reviewing the Prerequisites,
Processes, Key Work Products, Tasks and Work Products and Task Dependencies sections. You should use OUM as a guideline for performing all types of information
technology projects, but keep in mind that every project is different and that you need to adjust project activities according to each situation. Do not hesitate to add,
remove, or rearrange tasks, but be sure to reflect these changes in your estimates and risk management planning. You should also consider the depth to which you
address and complete each task based on the characteristics of your particular project or project increment. See Oracle's Full Lifecycle Method for Deploying Oracle-
Based Business Solutions for further information on the scalability and adaptability of OUM.
Back to Top
OBJECTIVES
The following is a list of the objectives of this phase:
Maintain enterprise-level IT processes that are to be continued, such as Governance and Reference Architecture once established by an Envision-based project.
Obtain and